☰

为什么不使用 UASP

tag-icon • tag-icon linux usb motherboard external-hard-drive usb-3
为什么不使用 UASP

根据如何检查Linux中USB3.0 UASP模式是否启用？，我的新硬盘盒上未使用 UASP说的是它支持UASP。

另外，我的主板（ASUS M5A99FX PRO R2.0）手册上写道：

USB 3.0 Boost 华硕 USB 3.0 Boost 技术支持最新的 USB 3.0 标准 UASP（USB 连接 SCSI 协议）。借助 USB 3.0 Boost 技术，USB 设备的传输速度可显著提高 170%，使原本就非常快速的 USB 3.0 传输速度更上一层楼。华硕软件可自动加速兼容 USB 3.0 外围设备的数据速度，无需任何用户交互。

因此有了主板支持和设备支持（以及Linux 支持)，为什么没有使用UASP，我该如何让它使用？

或者也许它正在被使用，而我只是不知道如何检查它。相关输出lsusb -t：

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

编辑
我在 Fedora 21（64 位）上运行 Linux 4.0.8。

编辑2
以下是输出lsmod | grep uas：

uas                    24576  0 
usb_storage            65536  1 uas

dmesg以下是打开扩展坞（其中装有 HDD）产生的所有输出：

[173791.566332] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[173791.581802] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa
[173791.581809] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[173791.581814] usb 2-2: Product: ASMT1053
[173791.581818] usb 2-2: Manufacturer: asmedia
[173791.581822] usb 2-2: SerialNumber: 123456789012
[173791.583705] usb-storage 2-2:1.0: USB Mass Storage device detected
[173791.583933] usb-storage 2-2:1.0: Quirks match for vid 174c pid 55aa: 400000
[173791.583981] scsi host11: usb-storage 2-2:1.0
[173792.587494] scsi 11:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
[173792.588048] sd 11:0:0:0: Attached scsi generic sg3 type 0
[173792.589870] sd 11:0:0:0: [sdc] Spinning up disk...
[173793.589663] .......ready
[173799.606012] sd 11:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[173799.606599] sd 11:0:0:0: [sdc] Write Protect is off
[173799.606606] sd 11:0:0:0: [sdc] Mode Sense: 43 00 00 00
[173799.607092] sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[173799.624914]  sdc: sdc2
[173799.626624] sd 11:0:0:0: [sdc] Attached SCSI disk

答案1

从看uas-检测.h我可以看到，您外壳中的 ASM1053 芯片确实受 UAS 驱动程序支持（即使它在大量传输中存在错误）。

您可以尝试修改 modules.alias 文件以添加对您的设备 ID 的支持。不幸的是，如果depmod系统上的任何东西再次运行，您将不得不重新对 modules.alias 文件进行这些更改。

第二种选择可能是修补 UAS 内核模块以宣传对您的设备 ID 的支持并重建模块。如果您这样做并将好的补丁推送回上游，您甚至可以让每个人都支持您的 HD 机箱 Linux UAS。

答案2

如果有人遇到类似问题偶然发现这个帖子......

与大多数设备驱动程序内核模块不同，usb-storage 和 uas 驱动程序不基于已知设备 ID 列表工作，而是都使用uas-检测.h文件的 uas_use_uas_driver() 函数根据设备是否声称支持 UAS 协议做出决定。（另请参阅这个 linuxquestions.org 主题关于设备别名。

在这种情况下，将一个或另一个模块列入黑名单不会有任何区别；如果 uas_use_uas_driver() 返回 true，则 uas.c 将声明它而 usb.c 将拒绝它，如果该函数返回 false，则会发生相反的情况。

（相反，有一个配置设置“usb-storage.quirks=VID:PID:u”，可用于确保设备不是被 uas 驱动程序认领，如内核的命令行参数文档。[没有强制其他方向的标志。]）

对于 OP 的问题：问题在于内核通常可以直接使用 USB ID 来确定设备是否需要特殊处理……但在 ID 0x174c:0x55aa 的情况下，ASMedia 已将相同的 ID 重复用于具有不同 UAS 支持级别的不同芯片组。因此，uas_use_uas_driver() 函数必须检查设备的特定属性，以尝试确定实际正在使用哪个芯片组，然后根据该属性决定是否为该设备使用 uas 驱动程序。不幸的是，当发生这种情况时，不会生成任何内核消息来明确说明它已做出的决定。

（大概可以结合 uas_use_uas_driver() 函数中的注释使用输出"lsusb -v -d174c:55aa"来确定特定设备上发生了什么以及为什么......但无论如何，请注意，检测逻辑不会查看插入设备时作为 dmesg 行的一部分打印的产品字符串 [例如“ASMT1053”] - 该名称实际上并没有告诉您有关 uas 检测逻辑将对该特定设备做出决定的任何信息。）

相关内容