我有一个程序，用于将大量文件写入具有 NTFS 文件系统的外部 USB-3 驱动器。这个程序似乎存在一些问题：一开始它会定期冻结几分钟，然后永久冻结。
该过程将无法中断。见屏幕截图：
。
等待通道是“read_descriptor”。所有这些进程（尝试启动多次）都打开了文件 /sys/.../usb4/descriptors。
在此状态下，似乎所有访问 USB 设备的命令都会冻结。包括：
lsusbcat /sys/kernel/debug/usb/devices- USB 重置脚本调用
/sys/..../unbind
在我尝试卸载分区后，使用umount --force（可能还有其他命令，现在不确定了）后，它确实卸载了，并且在调用时不再出现mount。然而在磁盘应用程序，它仍然显示为“正在卸载文件系统”。
磁盘上还有许多坏扇区（已经有 984 个了）。这是一个全新的驱动器。从 Linux 写入时似乎会出现坏扇区。
有没有办法重新启动 USB 子系统/强制断开设备连接，而无需重新启动系统？（update-grub也会阻止，并且引导加载程序菜单的默认设置设置错误，因此重新启动后我无法远程连接）。
那么什么原因可能导致 USB 驱动器出现此问题呢？
该系统在使用另一个外部 USB 驱动器时似乎也存在类似的问题（读取速度变慢，低于 1 MB/s）。
系统是 Ubuntu Linux，16.04.2 LTS，64 位机器上的 Xenial
更新：
lspci：
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller
00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
00:1c.3 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d0)
00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1
00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family H97 Controller
00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)
lsmod：
Module Size Used by
btrfs 987136 0
xor 24576 1 btrfs
raid6_pq 102400 1 btrfs
ufs 73728 0
qnx4 16384 0
hfsplus 106496 0
hfs 57344 0
minix 36864 0
ntfs 98304 0
msdos 20480 0
jfs 180224 0
xfs 970752 0
libcrc32c 16384 1 xfs
pci_stub 16384 1
vboxpci 24576 0
vboxnetadp 28672 0
vboxnetflt 28672 0
vboxdrv 454656 3 vboxnetadp,vboxnetflt,vboxpci
binfmt_misc 20480 1
snd_hda_codec_hdmi 53248 1
eeepc_wmi 16384 0
nvidia_uvm 745472 0
asus_wmi 28672 1 eeepc_wmi
mxm_wmi 16384 0
sparse_keymap 16384 1 asus_wmi
intel_rapl 20480 0
x86_pkg_temp_thermal 16384 0
intel_powerclamp 16384 0
coretemp 16384 0
kvm_intel 172032 0
kvm 544768 1 kvm_intel
irqbypass 16384 1 kvm
snd_hda_codec_realtek 86016 1
crct10dif_pclmul 16384 0
snd_hda_codec_generic 77824 1 snd_hda_codec_realtek
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
snd_hda_intel 40960 5
aesni_intel 167936 0
snd_hda_codec 135168 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_seq_midi 16384 0
aes_x86_64 20480 1 aesni_intel
snd_seq_midi_event 16384 1 snd_seq_midi
snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
lrw 16384 1 aesni_intel
snd_hwdep 16384 1 snd_hda_codec
gf128mul 16384 1 lrw
snd_rawmidi 32768 1 snd_seq_midi
glue_helper 16384 1 aesni_intel
snd_seq 69632 2 snd_seq_midi_event,snd_seq_midi
snd_pcm 106496 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
ablk_helper 16384 1 aesni_intel
snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi
cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_timer 32768 2 snd_pcm,snd_seq
snd 81920 21 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
mei_me 36864 0
soundcore 16384 1 snd
input_leds 16384 0
mei 98304 1 mei_me
lpc_ich 24576 0
shpchp 36864 0
serio_raw 16384 0
tpm_infineon 20480 0
8250_fintek 16384 0
wmi 20480 2 mxm_wmi,asus_wmi
acpi_pad 24576 0
mac_hid 16384 0
parport_pc 32768 1
ppdev 20480 0
lp 20480 0
parport 49152 3 lp,ppdev,parport_pc
autofs4 40960 2
hid_generic 16384 0
usbhid 49152 0
hid 118784 2 hid_generic,usbhid
uas 24576 8
usb_storage 69632 1 uas
nvidia_drm 53248 1
nvidia_modeset 778240 4 nvidia_drm
drm_kms_helper 155648 1 nvidia_drm
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
drm 364544 4 drm_kms_helper,nvidia_drm
nvidia 11931648 63 nvidia_modeset,nvidia_uvm
ahci 36864 3
e1000e 237568 0
libahci 32768 1 ahci
ptp 20480 1 e1000e
pps_core 20480 1 ptp
fjes 28672 0
video 40960 1 asus_wmi
答案1
如果“等待通道”处于“read_descriptor”状态，则意味着 USB 通道在相当严重的硬件问题后进入了重度恢复状态，因为“描述符阶段”仅在端口重置时发生，而端口重置仅在发生不可恢复的事务错误时发生。
事实上，它仅在 Windows 下运行，这意味着操作系统软件可能采用一些不同的硬件配置和控制器/PHY 参数。
我强烈怀疑链路电源管理 (LPM) 出了问题。Linux 发行版可能启用了所有最新和最好的功能，而 Windows 可能使用所谓的英特尔设计的“过滤驱动程序”来修复一些控制器缺陷。
LPM 状态 U1 和 U2 发生在硬件层面，因此从软件方面来看，它们可能是不可见的。要确定链接是否来回进入 LPM 状态，您需要超高速 USB 协议分析仪、Ellisys 280 或 Teledyne LeCroy Advisor T3，或者其他一些检测超高速链接上的 LPM 状态的工具，比如较便宜的工具。
答案2
这与我们在 USB 闪存设备上看到的情况一致。堆栈跟踪表明，在写入活动期间或写入活动之后立即发出的读取描述符的 EP0 SETUP 请求会导致不可恢复的情况。
这种情况并不普遍，因此这可能是某些 USB 设备标准合规性较差的又一案例。不过，Linux USB 大容量存储驱动程序也可能存在错误。
这是最近发生的协议分析器转储（大约有 1 GB 的写入立即进行，如下所示）。在最后一次写入完成后的 1 毫秒内，会读取描述符，此后设备不再响应进一步的写入。
