Prozesse, die auf ein USB-Gerät zugreifen, werden eingefroren und können nicht mehr unterbrochen werden

974
tmlen

Ich habe ein Programm, das eine große Anzahl von Dateien auf ein externes USB-3-Laufwerk mit NTFS-Dateisystem schreiben soll. Es scheint ein Problem zu geben: Zuerst friert es periodisch einige Minuten ein, dann friert es dauerhaft ein.

Der Prozess wird unterbrechungsfrei. Screenshot: system monitor.

Der Wartekanal ist "read_descriptor". Alle diese Prozesse (es wurde versucht, sie mehrmals zu starten) haben die Datei /sys/.../usb4/descriptors geöffnet.

In diesem Zustand scheinen alle Befehle, die auf das USB-Gerät zugreifen, einzufrieren. Einschließlich:

  • lsusb
  • cat /sys/kernel/debug/usb/devices
  • USB Reset-Skripts, die aufrufen /sys/..../unbind

Nachdem ich versucht hatte, die Partition zu deinstallieren, nachdem sie verwendet wurde umount --force(möglicherweise auch andere Befehle, nicht mehr genau weiß), wurde die Bereitstellung aufgehoben und beim Aufruf nicht mehr angezeigt mount. In der Anwendung " Festplatten" wird jedoch immer noch "Unmounting Filesystem" angezeigt.

Auch die Festplatte hat viele fehlerhafte Sektoren (984 bereits). Es ist ein völlig neuer Antrieb. Es scheint schlechte Sektoren zu bekommen, wenn Sie von Linux aus darauf schreiben.

Disks application

Gibt es eine Möglichkeit, das USB-Subsystem neu zu starten / das Gerät zu trennen, ohne das System neu zu starten? ( update-grubAuch blockiert und die Standardeinstellung des Bootloader-Menüs ist falsch eingestellt, sodass ich nach dem Neustart keine Remote-Verbindung herstellen kann).

Und was könnte dieses Problem mit dem USB-Laufwerk verursachen?

Das System schien auch ähnliche Probleme mit einem anderen externen USB-Laufwerk zu haben (Lesen verlangsamte sich auf weniger als 1 MB / s).

Das System ist Ubuntu Linux, 16.04.2 LTS, Xenial auf einer 64-Bit-Maschine

Update :

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 
0
Ist das Laufwerk ein SSD- oder HDD-Laufwerk? Sie sagen, Sie glauben, dass Linux-Schreiben dazu schlechte Sektoren verursacht. Ich meine damit, dass Sie Fenster auf dem gleichen Rechner haben, und es scheint nicht dasselbe Problem zu verursachen. Ist das richtig? Cliff Armstrong vor 6 Jahren 0
es ist hdd (LaCie Porsche Design 4 TB, Seagate-Laufwerk). ja unter windows macht es bo probleme: schrieb etwa 500GB drauf, nein es gab kein einfrieren und keine fehlersuche im dateisystem danach tmlen vor 6 Jahren 0
Sehr eigenartig. Sie haben Hardware als mögliche Ursache funktionell eliminiert. Ich kann mir nur vorstellen, dass es eine Inkompatibilität zwischen den Kernelmodulen und dem USB-Host gibt. Können wir ein "lspci" bekommen, um zu sehen, welche USB-Hosts Sie haben? `lsmod` kann auch nützlich sein, um zu sehen, welche Kernel-Module Ihr System verwendet. Cliff Armstrong vor 6 Jahren 0
hat es in die Post aufgenommen tmlen vor 6 Jahren 0
Es zeigt nicht das xhci (usb 3) -Modul, es könnte jedoch in den Kernel kompiliert werden. Was zeigt `lspci -v -s 14.0`? Cliff Armstrong vor 6 Jahren 0
Das ehci-Modul wird auch nicht angezeigt. `lspci -v -s 1d.0`? Cliff Armstrong vor 6 Jahren 0
Können Sie feststellen, ob LPM (Link Power Management) für diese beiden Betriebssysteme aktiviert / deaktiviert ist? Ale..chenski vor 6 Jahren 0
Wenn es einige große Dateien gab, könnten Sie "sudo mount -o big_writes / media /" verwenden. / dev /", wodurch verhindert wird, dass * fuse * große Dateien aufteilt, was für viele kleine Dateien jedoch nicht hilfreich ist. Eine andere Option ist das Mounten mithilfe der Option sync, wodurch Schreibvorgänge vor dem nächsten Start erzwungen werden. Siehe https://askubuntu.com/questions / 297029 / automount-with-async-option DrMoishe Pippik vor 6 Jahren 0
xhci und ehci schienen eingebaut zu sein. (Zeigt eine solche Meldung an, als versucht wurde, sie mit `modprobe` zu ​​deaktivieren) tmlen vor 6 Jahren 0
Gibt es für NTFS nicht ein Limit von 2,2 TB? Ale..chenski vor 6 Jahren 0
Es verursacht jetzt dasselbe Problem in Windows (E / A-Fehler beim Kopieren mit 7zip und dann `diskpart` und andere Anwendungen frieren ein). Es heißt nicht "Stromstoß am USB-Anschluss" oder "Gerät benötigt mehr Strom, als der Anschluss bereitstellen kann" und hängt nicht mehr an. Es ist ein USB-3-Laufwerk mit einem USB-C-Anschluss am Laufwerk. tmlen vor 6 Jahren 0

1 Antwort auf die Frage

1
Ale..chenski

Wenn sich der "wartende Kanal" im "read_descriptor" -Zustand befindet, bedeutet dies, dass der USB-Kanal nach einem ziemlich schwerwiegenden Hardwareproblem in eine schwere Wiederherstellung ging, da die "Deskriptorstufe" nur beim Zurücksetzen des Ports auftritt und das Zurücksetzen des Ports nur dann erfolgt, wenn eine Wiederherstellung nicht möglich ist Transaktionsfehler auftritt

Die Tatsache, dass es nur unter Windows funktioniert, bedeutet, dass die Betriebssystemsoftware wahrscheinlich unterschiedliche Hardwarekonfigurationen und Controller / PHY-Parameter verwendet.

Ich vermute stark, dass hier das Link Power Management (LPM) schuld ist. Die Linux-Distribution ermöglicht wahrscheinlich alle Schnickschnackereien und die neuesten und größten, während Windows möglicherweise einen sogenannten von Intel entwickelten "Filtertreiber" verwendet, um einige Controller-Mängel zu beheben.

Die LPM-Zustände U1 und U2 treten auf Hardwareebene auf und sind daher von der Softwareseite aus nicht sichtbar. Um festzustellen, ob der Link hin und her in LPM Staaten geht, müssen Sie einen Super-Speed - USB - Protokoll - Analysator, Ellisys 280 oder Teledyne LeCroy Advisor T3 oder ein anderes Werkzeug, das LPM Staaten auf Super-Speed - Link erkennen, wie diese viel weniger teures Werkzeug .

Handelt es sich bei den "fehlerhaften Sektoren" wahrscheinlich um Hardwareschäden oder einfach um logische Fehler im Dateisystem oder um Fehllesungen? tmlen vor 6 Jahren 0
@tmlen, schwer zu sagen. Das Problem hängt wahrscheinlich mit der USB-Schnittstelle zusammen, die zufällig hängt, aber in welchem ​​Ausmaß das SATA-Laufwerk beschädigt werden kann, weiß ich nicht. Nehmen Sie das Laufwerk heraus, stecken Sie es in ein normales SATA-Kabel und testen / formatieren Sie es gründlich mit einem funktionierenden vertrauenswürdigen Betriebssystem. Ale..chenski vor 6 Jahren 0