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

2024-08-29 17:08

本文主要是介绍第二十五篇:找微软的麻烦--在微软提供的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中发现的软件与硬件问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1118452

相关文章

线上Java OOM问题定位与解决方案超详细解析

《线上JavaOOM问题定位与解决方案超详细解析》OOM是JVM抛出的错误,表示内存分配失败,:本文主要介绍线上JavaOOM问题定位与解决方案的相关资料,文中通过代码介绍的非常详细,需要的朋... 目录一、OOM问题核心认知1.1 OOM定义与技术定位1.2 OOM常见类型及技术特征二、OOM问题定位工具

Vue3绑定props默认值问题

《Vue3绑定props默认值问题》使用Vue3的defineProps配合TypeScript的interface定义props类型,并通过withDefaults设置默认值,使组件能安全访问传入的... 目录前言步骤步骤1:使用 defineProps 定义 Props步骤2:设置默认值总结前言使用T

Web服务器-Nginx-高并发问题

《Web服务器-Nginx-高并发问题》Nginx通过事件驱动、I/O多路复用和异步非阻塞技术高效处理高并发,结合动静分离和限流策略,提升性能与稳定性... 目录前言一、架构1. 原生多进程架构2. 事件驱动模型3. IO多路复用4. 异步非阻塞 I/O5. Nginx高并发配置实战二、动静分离1. 职责2

解决升级JDK报错:module java.base does not“opens java.lang.reflect“to unnamed module问题

《解决升级JDK报错:modulejava.basedoesnot“opensjava.lang.reflect“tounnamedmodule问题》SpringBoot启动错误源于Jav... 目录问题描述原因分析解决方案总结问题描述启动sprintboot时报以下错误原因分析编程异js常是由Ja

MySQL 表空却 ibd 文件过大的问题及解决方法

《MySQL表空却ibd文件过大的问题及解决方法》本文给大家介绍MySQL表空却ibd文件过大的问题及解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考... 目录一、问题背景:表空却 “吃满” 磁盘的怪事二、问题复现:一步步编程还原异常场景1. 准备测试源表与数据

解决Nginx启动报错Job for nginx.service failed because the control process exited with error code问题

《解决Nginx启动报错Jobfornginx.servicefailedbecausethecontrolprocessexitedwitherrorcode问题》Nginx启... 目录一、报错如下二、解决原因三、解决方式总结一、报错如下Job for nginx.service failed bec

SysMain服务可以关吗? 解决SysMain服务导致的高CPU使用率问题

《SysMain服务可以关吗?解决SysMain服务导致的高CPU使用率问题》SysMain服务是超级预读取,该服务会记录您打开应用程序的模式,并预先将它们加载到内存中以节省时间,但它可能占用大量... 在使用电脑的过程中,CPU使用率居高不下是许多用户都遇到过的问题,其中名为SysMain的服务往往是罪魁

MySQ中出现幻读问题的解决过程

《MySQ中出现幻读问题的解决过程》文章解析MySQLInnoDB通过MVCC与间隙锁机制在可重复读隔离级别下解决幻读,确保事务一致性,同时指出性能影响及乐观锁等替代方案,帮助开发者优化数据库应用... 目录一、幻读的准确定义与核心特征幻读 vs 不可重复读二、mysql隔离级别深度解析各隔离级别的实现差异

C++ vector越界问题的完整解决方案

《C++vector越界问题的完整解决方案》在C++开发中,std::vector作为最常用的动态数组容器,其便捷性与性能优势使其成为处理可变长度数据的首选,然而,数组越界访问始终是威胁程序稳定性的... 目录引言一、vector越界的底层原理与危害1.1 越界访问的本质原因1.2 越界访问的实际危害二、基

Python多线程应用中的卡死问题优化方案指南

《Python多线程应用中的卡死问题优化方案指南》在利用Python语言开发某查询软件时,遇到了点击搜索按钮后软件卡死的问题,本文将简单分析一下出现的原因以及对应的优化方案,希望对大家有所帮助... 目录问题描述优化方案1. 网络请求优化2. 多线程架构优化3. 全局异常处理4. 配置管理优化优化效果1.