USB3.0 Festplatte kann nicht gemountet/formatiert werden

[ulischmidthaase]

Das Problem, welches ich mit meiner frisch erworbenen USB3.0 Festplatte ähnelt wohl dem hier https://linux-club.de/forum/viewtopic.php?f=90&t=122787&sid=273d4225d255cddab62b56268f4823a0 vor allem in der Fragestellung: Festplatte Schrott?
Ich habe mir eine USB-SSD Festplatte zugelegt, welche sich offensichtlich nicht formatieren lässt :???: Im Yast Partitionierungs Tool wird die Platte unter /dev/sdk ohne Partitionen angezeigt. Versuche ich eine Partition anzulegen (egal welcher Art) erhalte ich folgende Fehlermeldung

GPT wird auf /dev/sdk erstellt

Unerwartete Situation im System festgestellt.

Klicken Sie unten, um weitere Details anzuzeigen (nur auf Englisch).

Trotz des Fehlers fortfahren?

Unter Details steht zu lesen: (kopieren war leider nicht möglich, daher hier der Text)
command '/usr/sbin/parted' --script '/dev/sdk' mklabel gpt' failed:
stderr:

Warning: Error fsyncing/closing /dev/sdk: Remote I/O error
Error: Input/output error during read on /dev/sdk
Warning: Error fsyncing/closing /dev/sdk: Remote I/O error
Error: Input/output error during write on /dev/sdk
Warning: Error fsyncing/closing /dev/sdk: Input/output error

exit code:
1

linux-2m0a:/home/uli # gdisk -l /dev/sdk
GPT fdisk (gdisk) version 1.0.1

Warning! Read error 5; strange behavior now likely!
Warning! Read error 5; strange behavior now likely!
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk /dev/sdk: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C9E588A8-7B92-467A-A07C-8E7990D31227
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1953525101 sectors (931.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Ist da was zu retten?

 

[spoensche]

Hast du mal ein anderes Kabel oder einen anderen USB Port an deinem Rechner ausprobiert?

Unterstütz dein Rechner USB 3.0?
Wie alt ist die Hardware, die bei dir verbaut ist?

 

[susejunky]

Hallo ulischmidthaase,

Das Problem, welches ich mit meiner frisch erworbenen USB3.0 Festplatte ... Ich habe mir eine USB-SSD Festplatte zugelegt, welche sich offensichtlich nicht formatieren lässt :???

Verfügt diese Festplatte über einen Schreibschutz-Schalter?

Bitte zeige die Log-Meldungen (dmesg), die beim Anstecken der Festplatte erzeugt werden und die Ergebnisse von

# hwinfo --disk

Viele Grüße

susejunky

 

[ulischmidthaase]

Mal von hinten nach vorne: Ausgabe von

hwinfo --disk

ergibt

32: USB 00.0: 10600 Disk
  [Created at usb.122]
  Unique ID: rg_L.sFNgsRScOu7
  Parent ID: zPk0.vNHThQQZKpC
  SysFS ID: /devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-2/4-2:1.0
  SysFS BusID: 4-2:1.0
  Hardware Class: disk
  Model: "JMicron Technology Corp. / JMicron USB 3.0"
  Hotplug: USB
  Vendor: usb 0x152d "JMicron Technology Corp. / JMicron USA Technology Corp."
  Device: usb 0x0583 "USB 3.0"
  Revision: "2.09"
  Serial ID: "DD564198838A2"
  Driver: "uas"
  Driver Modules: "uas"
  Module Alias: "usb:v152Dp0583d0209dc00dsc00dp00ic08isc06ip62in00"
  Driver Info #0:
    Driver Status: uas is active
    Driver Activation Cmd: "modprobe uas"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #43 (Hub)

Festplatte ein undausgesteckt ergibt folgenden Eintrag dmesg:

[So Jul 14 22:04:35 2019] usb 4-2: USB disconnect, device number 2
[So Jul 14 22:04:35 2019] sd 10:0:0:0: [sdk] Synchronizing SCSI cache
[So Jul 14 22:04:35 2019] sd 10:0:0:0: [sdk] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[So Jul 14 22:04:40 2019] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[So Jul 14 22:04:40 2019] usb 4-1: New USB device found, idVendor=152d, idProduct=0583
[So Jul 14 22:04:40 2019] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Jul 14 22:04:40 2019] usb 4-1: Product: USB 3.0
[So Jul 14 22:04:40 2019] usb 4-1: Manufacturer: KESU
[So Jul 14 22:04:40 2019] usb 4-1: SerialNumber: DD564198838A2
[So Jul 14 22:04:40 2019] scsi host10: uas
[So Jul 14 22:04:40 2019] scsi 10:0:0:0: Direct-Access     KESU     USB 3.0          0209 PQ: 0 ANSI: 6
[So Jul 14 22:04:40 2019] sd 10:0:0:0: Attached scsi generic sg12 type 0
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] 4096-byte physical blocks
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Write Protect is off
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Mode Sense: 53 00 00 08
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Attached SCSI disk

Schreibschutzschalter habe ich keinen gesehen, das Gehäuse lässt sich auch nicht öffnen.

Hast du mal ein anderes Kabel oder einen anderen USB Port an deinem Rechner ausprobiert?

Kabel habe ich kein anderes als jenes welches mitgeliefert wurde (Anschluss am Festplattengehäuse) Mein Board ist glaub so um die 7 Jahre alt, hat diverse USB2.0 und 2 USB3.0 Anschlüsse. Die Festplatte wird NUR an den beiden USB3.0 Anschlüssen erkannt.

 

[susejunky]

Hallo ulischmidthaase,

... Die Festplatte wird NUR an den beiden USB3.0 Anschlüssen erkannt.

danke für die Daten. Um das Problem jedoch weiter untersuchen zu können, wären folgende Informationen auch noch hilfreich:

Betriebssystem + Version (z.B.: openSUSE Leap 15.1 Kernel 4.12.14-lp151.28.7-default))
verwendeter Desktop (z.B. KDE, Plasma 5.12.8, Frameworks 5.55.0, Qt 5.9.7)
Motherboard (z.B. MSI MS-7915)

Viele Grüße

susejunky

 

[josef-wien]

Die Festplatte wird NUR an den beiden USB3.0 Anschlüssen erkannt.

Das scheint darauf hinzudeuten, daß die USB 2-Anschlüsse nicht genügend Strom zur Verfügung stellen können.

Um welche Platte handelt es sich (hwinfo und dmesg zeigen ja den Protokollkonverter):

hdparm -I /dev/sdk

Falls der Protokollkonverter S.M.A.R.T. unterstüzt:

smartctl -a /dev/sdk

Rein gefühlsmäßig halte ich einen Defekt des Geräts für wahrscheinlich und somit eine Reklamation beim Händler für notwendig.

 

[ulischmidthaase]

Auch hier wieder von hinten angefangen: Motherboard ist ein Intel DH67BL mit einem i5 (2.Gen) und 8 Gb RAM. Beim Betriebssystem schaut es ein wenig komplizierter, weil allgemeingültiger aus: Die gemachten Angaben beziehen sich auf eine (immer brav aktualisiertes) OpenSuSE 15.0 mit KDE/waveland. Im System ist hier außerdem ein frisch aktualisiertes OpenSuSE 15.1 sowie ein (natürlich nicht mehr aktualisiertes) 12.3 . Die gemachten Angaben liefert sowohl die 15.1 als auch die 15.1 . Um mir eine Möglichkeit zu schaffen das ganze System ordentlicher zu gestalten hatte ich mir im Übrigen die Festplatte ursprünglich zugelegt aber das gibt zu gegebener Zeit einen neuen Fred

 

[Anonymous]

hwinfo --disk

ergibt

32: USB 00.0: 10600 Disk
  [Created at usb.122]
  Unique ID: rg_L.sFNgsRScOu7
  Parent ID: zPk0.vNHThQQZKpC
  SysFS ID: /devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-2/4-2:1.0
  SysFS BusID: 4-2:1.0
  Hardware Class: disk
  Model: "JMicron Technology Corp. / JMicron USB 3.0"
  Hotplug: USB
  Vendor: usb 0x152d "JMicron Technology Corp. / JMicron USA Technology Corp."
  Device: usb 0x0583 "USB 3.0"
  Revision: "2.09"
  Serial ID: "DD564198838A2"
  Driver: "uas"
  Driver Modules: "uas"
  Module Alias: "usb:v152Dp0583d0209dc00dsc00dp00ic08isc06ip62in00"
  Driver Info #0:
    Driver Status: uas is active
    Driver Activation Cmd: "modprobe uas"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #43 (Hub)

Festplatte ein undausgesteckt ergibt folgenden Eintrag dmesg:

[So Jul 14 22:04:35 2019] usb 4-2: USB disconnect, device number 2
[So Jul 14 22:04:35 2019] sd 10:0:0:0: [sdk] Synchronizing SCSI cache
[So Jul 14 22:04:35 2019] sd 10:0:0:0: [sdk] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[So Jul 14 22:04:40 2019] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[So Jul 14 22:04:40 2019] usb 4-1: New USB device found, idVendor=152d, idProduct=0583
[So Jul 14 22:04:40 2019] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[So Jul 14 22:04:40 2019] usb 4-1: Product: USB 3.0
[So Jul 14 22:04:40 2019] usb 4-1: Manufacturer: KESU
[So Jul 14 22:04:40 2019] usb 4-1: SerialNumber: DD564198838A2
[So Jul 14 22:04:40 2019] scsi host10: uas
[So Jul 14 22:04:40 2019] scsi 10:0:0:0: Direct-Access     KESU     USB 3.0          0209 PQ: 0 ANSI: 6
[So Jul 14 22:04:40 2019] sd 10:0:0:0: Attached scsi generic sg12 type 0
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] 4096-byte physical blocks
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Write Protect is off
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Mode Sense: 53 00 00 08
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[So Jul 14 22:04:41 2019] sd 10:0:0:0: [sdk] Attached SCSI disk

Der Fall ist glasklar: Der USB3-SATA-Konverter-Chip von JMicron dieser Festplatte macht im UASP-Modus unter Linux massive Probleme.
UASP = USB Attached SCSI Protocol

Dazu gibt es bereits dutzende Infos im Netz und auch „Umschiffungen“ im Linux Kernel:
github.com/torvalds/linux/blob/master/drivers/usb/storage/unusual_uas.h
Das heißt: entweder abwarten, bis im Kernel von openSUSE für genau diesen JMicron-Chip ein Workaround integriert ist oder eine andere externe Festplatte kaufen.

Du könntest auch versuchen, in Leap 15.0 / 15.1 für diese ext. Festplatte UASP zu deaktivieren, sodass sie im BOT-Modus (=Bulk Only Transport) betrieben wird. Das funktioniert auf jeden Fall, nur eben im Durchschnitt 10–15% langsamer.
Unter openSUSE 12.3 läuft die Festplatte, denn im Linux-Kernel 3.7 war UAS noch nicht implementiert. Probiere es aus!

 

[susejunky]

Hallo ulischmidthaase,

... Die gemachten Angaben beziehen sich auf eine (immer brav aktualisiertes) OpenSuSE 15.0 mit KDE/waveland.

danke für die Informationen.

Ich nutze hier ebenso openSUSE Leap 15.0 und habe eine Raidsonic Icy Box IB-1817M-C31 bestückt mit einer Samsung SSD 960 EVO. Die Kombination funktioniert problemlos, auch unter 15.0 mit kernel-default-5.2.1-2.1.gbf5c01b oder unter 15.1 oder unter Tumbleweed.

Wenn ich das Gerät anstecke zeigt dmesg

[   67.287611] usb 3-8: new high-speed USB device number 6 using xhci_hcd
[   67.436143] usb 3-8: New USB device found, idVendor=152d, idProduct=0583
[   67.436144] usb 3-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   67.436144] usb 3-8: Product: USB to PCIE Bridge
[   67.436145] usb 3-8: Manufacturer: JMicron
[   67.436145] usb 3-8: SerialNumber: 0123456789ABCDEF
[   67.444002] usbcore: registered new interface driver usb-storage
[   67.445365] scsi host6: uas
[   67.445663] scsi 6:0:0:0: Direct-Access     JMicron  Generic          3102 PQ: 0 ANSI: 6
[   67.446098] sd 6:0:0:0: Attached scsi generic sg3 type 0
[   67.446258] usbcore: registered new interface driver uas
[   70.033213] sd 6:0:0:0: [sdc] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[   70.033214] sd 6:0:0:0: [sdc] 4096-byte physical blocks
[   70.033345] sd 6:0:0:0: [sdc] Write Protect is on
[   70.033346] sd 6:0:0:0: [sdc] Mode Sense: 6b 00 80 08
[   70.033583] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   70.051308]  sdc: sdc1 sdc2 sdc3 sdc4 sdc5 sdc6 sdc7 sdc8 sdc9 sdc10
[   70.052842] sd 6:0:0:0: [sdc] Attached SCSI disk

Vergleicht man das mit der von Dir hier gezeigten Ausgabe von dmesg so kann man erkennen

• sowohl Dein als auch mein Gehäuse verwenden diesen Kontroller: http://www.jmicron.com/PDF/brief/jms583.pdf
• bei Dir wird der Kontroller-Hersteller nicht mit JMicron sondern mit KESU bezeichnet
• bei Dir wird der usb-storage Treiber nicht geladen

Möglicherweise schafft ein manuelles Nachladen des usb-storage-Treibers abhilfe.

smartctl liefert bei mir, auch mit

# smartctl -a -d usbjmicron /dev/sdc

keine verwertbaren Ergebnisse, ebensowenig wie hdparm.

Dass die USB-Stromversogung Probleme bereitet halte ich bei einer SSD eher für unwahrscheinlich. Mein nunmehr 12 Jahre altes Notebook kann eine an USB2.0 angeschlossene, rotierende 2,5"-Festplatte (ohne externe Stromversorgung) problemlos nutzen und deren Anlaufstrom liegt mit 1A (laut Datenblatt) sicherlich über dem was eine moderne SSD im Betrieb benötigt.

Viele Grüße

susejunky

 

[josef-wien]

bei Dir wird der usb-storage Treiber nicht geladen

Er wird, denn uas setzt usb-storage voraus.

Der nächste Schritt sollte also sein, den aktuellen Kernel aus dem Repo http://download.opensuse.org/repositories/Kernel:/stable/standard/ zu installieren.

P. S. Es gibt einige SSD, deren Einschaltstrom sogar die USB 3-Spezifikation deutlich überschreitet. Das kann einen USB 2-Anschluß durchaus überfordern.

 

[susejunky]

Hallo josef-wien,

bei Dir wird der usb-storage Treiber nicht geladen

Er wird, denn uas setzt usb-storage voraus.

woraus leitest Du das ab?

Während meine dmesg-Ausgabe die beiden Meldungen

[   67.444002] usbcore: registered new interface driver usb-storage
[   67.446258] usbcore: registered new interface driver uas

ausweist, sind in der Ausgabe, die ulischmidthaase am 14.07.2019, 21:17 Uhr hier gezeigt hat, beide Einträge nicht zu finden.

Der nächste Schritt sollte also sein, den aktuellen Kernel aus dem Repo http://download.opensuse.org/repositories/Kernel:/stable/standard/ zu installieren.

Das ist sicherlich ein Versuch wert. Aber bei mir funktioniert der selbe Kontroller auch mit den Standard-Kerneln von openSUSE Leap 15.0 und 15.1.

Viele Grüße

susejunky

 

[Anonymous]

Mein nunmehr 12 Jahre altes Notebook kann eine an USB2.0 angeschlossene, rotierende 2,5"-Festplatte (ohne externe Stromversorgung) problemlos nutzen und deren Anlaufstrom liegt mit 1A (laut Datenblatt) sicherlich über dem was eine moderne SSD im Betrieb benötigt.

Tja, allerdings ist es bei den allermeisten Notebook so, dass sich zwei benachbarte USB-Buchsen eine abgesichterte Spannungquelle teilen. Statt jede USB-Buchse einzeln abzusichern, sind es Zwei. Daher liefert die einzelne USB-Buchse zumeist über 1A Strom und beide zusammen 2×500mA. So etwas wird sogar bei etlichen Motherboards gemacht. Es ist billiger.
 

Vergleicht man das mit der von Dir hier gezeigten Ausgabe von dmesg so kann man erkennen

• sowohl Dein als auch mein Gehäuse verwenden diesen Kontroller: http://www.jmicron.com/PDF/brief/jms583.pdf
• bei Dir wird der Kontroller-Hersteller nicht mit JMicron sondern mit KESU bezeichnet
• bei Dir wird der usb-storage Treiber nicht geladen

Woraus leitest du das ab?

Im Übrigen ist dein verlinktes Datenblatt von JMicron ein JMS583 USB 3.1 Gen 2 to PCIe Gen3x2 Chip.
In einem ext. Gehäuse für USB3 mit interner SATA-HDD wirst du so etwas nicht finden.

 

[Gräfin Klara]

Tja, allerdings ist es bei den allermeisten Notebook so, dass sich zwei benachbarte USB-Buchsen eine abgesichterte Spannungquelle teilen. Statt jede USB-Buchse einzeln abzusichern, sind es Zwei. Daher liefert die einzelne USB-Buchse zumeist über 1A Strom und beide zusammen 2×500mA. So etwas wird sogar bei etlichen Motherboards gemacht. Es ist billiger.

Eine solche Lösung kann ich mir nicht vorstellen

 

[Anonymous]

Eine solche Lösung kann ich mir nicht vorstellen

Dann schraub' die Geräte der Reihe nach auf und sieh nach!
Sogar bei USB-Hubs mit eigenem Netzteil wird das in der Regel praktiziert. Anders könnte eine einzelne USB 1.1 / USB 2-Buchse nie über 500mA Strom liefern, auch wenn das eine Verletzung der USB-Spezifikation darstellt.

 

[Gräfin Klara]

Dann schraub' die Geräte der Reihe nach auf und sieh nach!
Sogar bei USB-Hubs mit eigenem Netzteil wird das in der Regel praktiziert. Anders könnte eine einzelne USB 1.1 / USB 2-Buchse nie über 500mA Strom liefern, auch wenn das eine Verletzung der USB-Spezifikation darstellt.

Das ist nicht richtig was du schreibst. So könnte das nicht funktionieren.

 

[josef-wien]

woraus leitest Du das ab?

Überzeuge Dich selbst:

modinfo uas | grep depends

meine dmesg-Ausgabe

Sofern Du nicht manuell entlädst, findest Du im laufenden System die beiden Zeilen nur einmal, nämlich dann, wenn das Modul geladen wird.

Aber bei mir funktioniert der selbe Kontroller auch mit den Standard-Kerneln von openSUSE Leap 15.0 und 15.1.

Nachdem ASMedia dieselbe Product-ID bei unterschiedlichen Protokollkonvertern verwendet hat, mag das bei JMicron ja auch der Fall sein (und dann wird es wieder kompliziert für die Kernel-Entwickler). Daher kann der Versuch mit dem aktuellen stabilen Kernel nicht schaden. Ansonsten landen wir wohl wieder bei:

Rein gefühlsmäßig halte ich einen Defekt des Geräts für wahrscheinlich

 

[susejunky]

Hallo josef-wien,

... Überzeuge Dich selbst:

modinfo uas | grep depends

Nun die Abhängigkeit an sich, wollte ich eigentlich nicht in Frage stellen ..

... Sofern Du nicht manuell entlädst, findest Du im laufenden System die beiden Zeilen nur einmal, nämlich dann, wenn das Modul geladen wird.

... ich war vielmehr davon ausgegangen, dass ulischmidthaase die Meldungen, die beim allerersten Verbinden ausgegeben wurden, gezeigt hätte.

Aber das ist zugegebenermaßen eine reine Annahme meinerseits !

@ ulischmidthaase
Könntest Du bitte den Log zeigen, der beim allerersten Anstecken geschrieben wird.

Viele Grüße

susejunky

 

[Anonymous]

Dann schraub' die Geräte der Reihe nach auf und sieh nach!
Sogar bei USB-Hubs mit eigenem Netzteil wird das in der Regel praktiziert. Anders könnte eine einzelne USB 1.1 / USB 2-Buchse nie über 500mA Strom liefern, auch wenn das eine Verletzung der USB-Spezifikation darstellt.

Das ist nicht richtig was du schreibst. So könnte das nicht funktionieren.

Was bitte könnte so nicht funktionieren?

Mir scheint, du hast keine Ahnung, was alles trotz Verletzung der USB-Spezifikation funktioniert.
Mal nur ein Beispiel, um dieses Thema nicht mit unpassendem Informationen aufzublähen:
heise.de/ct/ausgabe/2014-18-USB-Hubs-koennen-PCs-und-Notebooks-beschaedigen-2284094
Der maximale Strom pro USB-Buchse wird hier — wie bei sehr vielen anderen Produkten, wie z.B. leider auch bei billigen USB3-PCI-Express Steckkarten — nur durch das Netzteil begrenzt. Da können im Beispiel mit dem USB-Hub locker 4 A Strom über eine USB-Buchse fließen. Bei einer PCIe-Karte könnten es 20 A sein. Irgend etwas raucht dann natürlich ab.

Normalerweise muss jedem USB-Gerät, das mehr als 500 mA Strom benötigt, ein eigenes Netzteil gewidmet sein. Da das aber Geld kostet, haben sich die Hersteller mit sogenannten Y-Kabeln beholfen, die aber eine grobe Verletzung des USB-Standards darstellen. Bei USB3.x ist zwar der maximale Strom auf 900 mA angehoben worden, externe 2,5-Zoll-Festplatten und optische Slim-Laufwerke haben aber Einschaltströme von typisch 1,1 A.

Vorbildlich sind hier Computer der Firma Apple Inc.
Nimmt ein USB-Gerät zu viel Strom auf, wird es dauerhaft (per Schalttransitoren) vom Rechner getrennt und es erscheint eine Fehlermeldung auf dem Bildschirm, dass dieses „genau bezeichnete“ Gerät zu viel Strom zieht, also möglicherweise einen Defekt hat und deswegen deaktiviert wurde.
Qualität hat aber ihren Preis.

 

[Gräfin Klara]

Was bitte könnte so nicht funktionieren?

Einiges

Mir scheint, du hast keine Ahnung, was alles trotz Verletzung der USB-Spezifikation funktioniert.

Auf dieses Schreiben habe ich im Grunde gar keine Lust und es passt auch nur indirekt zum Thema.
Aber dein "du hast keine Ahnung" ist sehr beunruhigend. Deshalb will und kann ich das so nicht stehen lassen.


--
Mit PS meine ich das Power Supply des PC.
Mit device meine ich irgendein angestöpseltes USB-Gerät.
Mit NT ein externes Netzteil zur Spannungsversorgung eines devices HUB.
--

Mal nur ein Beispiel, um dieses Thema nicht mit unpassendem Informationen aufzublähen:
heise.de/ct/ausgabe/2014-18-USB-Hubs-koennen-PCs-und-Notebooks-beschaedigen-2284094

Dieser Artikel von heise.de stellt das Problem in Teilen falsch dar. Das führt zu Missverständnissen.

Bei direkter Kopplung der 5-Volt-Leitungen aller Ports könnte dann die Last des Hub-Chips und sämtlicher
angeschlossenen USB-Geräte die Host-Buchse überlasten

Das ist falsch, weil es eine solche "direkte Koppelung" der 5-Volt-Leitungen aller Ports nicht geben kann. Um das zu verstehen, muß
erst einmal klar sein, dass diese "5-Volt-Leitungen" keine Spannungsversorgungen sind, sondern getrennte Stromquellen. In diesem
von Heise angeführten Beispiel mit dem NT kommt es zu parasitären Stromflüssen, die auf Grund des Spannungsunterschiedes zwischen
NT und PS bei Nicht-Entkoppelung zwangsläufig auftreten müssen. In welche Richtung der Strom fließt, hängt von der Spannung des NT
und vom Konfigurationszustand des Kanals ab. Diese Stromrichtung ist wesentlich für das Verstehen zum Geschehen an einem HUB-Kanal.
Dieses Thema kommt in dieser Beschreibung aber nicht vor, was aber wichtig wäre. Denn nicht alles was verboten aussieht, ist auch
verboten. Das gilt natürlich auch umgekehrt.

Der maximale Strom pro USB-Buchse wird hier .. nur durch das Netzteil begrenzt. Da können im Beispiel mit dem USB-Hub locker 4 A Strom über eine USB-Buchse fließen.

Wieso schreibst du sowas?
Wenn eine Entkoppelung im HUB vorhanden ist, dann wird der PC-HUB überhaupt nicht belastet.
Wenn keine Entkoppelung vorhanden ist, dann wird dieser PC-HUB-Kanal mit dem oben beschriebenen parasitären Strom belastet.
Von einem Strom aus dem PS von "locker 4 A über eine USB-Buchse" kann in beiden Fällen keine Rede sein und
eine Verdrahtung wie abgebildet, die das NT als die gemeinsame Stromquelle zeigt, funktioniert so nicht.
So ein HUB ist ja Teil eines Netzwerkes und nicht einfach ein verdrahteter Kasten.
Jeder einzelne Kanal wird über Protokoll mit dem PC-HUB separat verhandelt, so als wäre er ein interner HUB.

Stromquelle am HUB-Kanal:
JEDER HUB-Kanal, also jede einzelne Buchse, stellt in seiner Grundkonfiguration einen Strom von 100 bzw. 150mA zur Verfügung.
DIESE 100mA Obergrenze ist klar als max. definiert, mehr darf es nicht sein. Diese Konstantstromquelle dient zur Messung
des Zustandes EINES devices JE Kanal und wird vom OS als auch BIOS so vorausgesetzt und auch so verwendet. Das erfolgt bei der
sogenannten Enumeration. Diese Definition von MAX. der 100mA wird oft auch den 500mA angedichtet. Das stimmt so aber nicht.

Enumeration (simple Erklärung ohne Protokollierung):
Die Enumeration, die auch das BIOS beherrscht (sonst gäbe es ja keine Erkennung von devices beim Bootprozess), setzt eine strikte
Trennung der Stromquellen je Kanal voraus. Die Erkennung eines devices erfolgt auf Grund von pull-ups am USB-Datenbus. Wird ein
device erkannt, (dafür müssen die 100mA ausreichen), wird der Strom erhöht (500mA oder auch MEHR). Dann wird die Spannung gemessen
und bei zu geringer Spannung (Überstrom), wird nur dieser eine Kanal wieder auf 100mA reduziert oder ganz abgeschalten. Kein
anderes device an diesem HUB darf durch dieses fehlerhafte device beeinflusst werden. Das ist Standard und kann nicht einfach durch
eine Billiglösung mit einer gemeinsamen Konstantstromquelle für mehrere Buchsen umgangen werden. Mit einer Schaltung, wie sie von
dir und Heise angenommen wird, würde der gesamte Enumerationsprozess für die device Erkennung nicht mehr funktionieren. Diese
Vergemeinerung der Stromquelle würde Interferenzen zwischen allen Kanälen verursachen. Jeder Spannungseinbruch, verursacht durch ein
device wegen kurzzeitiger Stromspitzen z.B. bei Einschalteprozessen (ERLAUBTE Toleranz an EINEM USB-Kanal), würde alle anderen
devices wie keyboard oder mouse am selben HUB wegen angeblichem Überstrom abschalten, weil die gemeinsame Konstantstromquelle an
allen devices den erlaubten Spannungswert unterschreiten würde. Eine solche Spezialschaltung traue ich nicht einmal den Chinesen
zu. Dein anderer Hinweis, dass die Konstantstromquellen der Ausgangsstufen überbrückt werden und so der Strom nur noch vom PS
begrenzt wird, ist wenig wahrscheinlich. Es müsste direkt an der USB-Buchse gelötet werden und es käme zu genau dem Effekt, wie von
Heise beschrieben. Parasitäre Ströme zwischen Kanal-Ausgangsdriver und PS würden den HUB auf Dauer wegen erhöhtem Stromfluss zerstören.

... wie z.B. leider auch bei billigen USB3-PCI-Express Steckkarten — nur durch das Netzteil begrenzt

Wie das bei USB3-PCI-Express Steckkarten ist, das kann ich nicht beurteilen. Sollten die aber einen eigenen USB-Hub auf ihrer Karte
verbaut haben, dann kann ich mir eine solche Schaltung nicht vorstellen, weil sie weder Einsparung noch Sinn ergeben.
Im Gegenteil, es wäre ein sinnloser Mehraufwand mit Schadensgarantie.

Normalerweise muss jedem USB-Gerät, das mehr als 500 mA Strom benötigt, ein eigenes Netzteil gewidmet sein.

Das ist natürlich richtig. Die 500mA müssen laut Standard z.B. 2.0 an ein erfolgreich enumeriertes device geliefert werden.
Mehr kann sein, darf aber vom Entwickler eines devices nicht angenommen werden. Es gibt HUB-Controller, deren Ausgangsdriver mit
800mA angegeben sind. Das ist nicht verboten und bricht auch keine Standards. Die Schaltschwelle an der 5V Spannung kann ja per
Software pro Kanal geändert werden und damit ändert sich auch der Abschaltpunkt. Je niedriger der gewählte Spannungswert, umso mehr
Strom darf das device ziehen. Zwischen 5V und 3,8V (um die typische Versorgung von 3.3V am device zu gewährleisten), ist eine Menge
Holz. Dafür braucht es keine Tricks.

Vorbildlich sind hier Computer der Firma Apple Inc.
Nimmt ein USB-Gerät zu viel Strom auf, wird es dauerhaft (per Schalttransitoren) vom Rechner getrennt und es erscheint eine Fehlermeldung auf dem Bildschirm, dass dieses „genau bezeichnete“ Gerät zu viel Strom zieht, also möglicherweise einen Defekt hat und deswegen deaktiviert wurde.
Qualität hat aber ihren Preis.

Auch Apple hat nichts Neues erfunden, die verbauen auch nur die am Markt erhältlichen Controller für Hubs, genau so wie alle
anderen. Und alle diese Controller arbeiten nach dem Prinzip, wie oben vereinfacht beschrieben, weil das BIOS damit können muß.
Das gilt für alle, auch für Apple.

Gruß
Gräfin Klara

 

[Anonymous]

Dieser Artikel von heise.de stellt das Problem in Teilen falsch dar. Das führt zu Missverständnissen.

Bei direkter Kopplung der 5-Volt-Leitungen aller Ports könnte dann die Last des Hub-Chips und sämtlicher
angeschlossenen USB-Geräte die Host-Buchse überlasten

Das ist falsch, weil es eine solche "direkte Koppelung" der 5-Volt-Leitungen aller Ports nicht geben kann. Um das zu verstehen, muß erst einmal klar sein, dass diese "5-Volt-Leitungen" keine Spannungsversorgungen sind, sondern getrennte Stromquellen.

Das ist aber eine gewagte Aussage!
Du kennst selber ja noch nicht einmal den Unterschied zwischen Spannungsquelle und Stromquelle.
 

[…]

Der maximale Strom pro USB-Buchse wird hier .. nur durch das Netzteil begrenzt. Da können im Beispiel mit dem USB-Hub locker 4 A Strom über eine USB-Buchse fließen.

Wieso schreibst du sowas?
Wenn eine Entkoppelung im HUB vorhanden ist, dann wird der PC-HUB überhaupt nicht belastet.
Wenn keine Entkoppelung vorhanden ist, dann wird dieser PC-HUB-Kanal mit dem oben beschriebenen parasitären Strom belastet.

Wo hast du diese Ausdrucksweise gelernt?
Da stehen jedem (gelernten) Elektroniker die Haare zu Berge.
Und warum ich „sowas” schreibe? — Na, weil es jeder Auszubildende Mitte des 1. Lehrjahres so oder so ähnlich formulieren würde.
 

Von einem Strom aus dem PS von "locker 4 A über eine USB-Buchse" kann in beiden Fällen keine Rede sein und
eine Verdrahtung wie abgebildet, die das NT als die gemeinsame Stromquelle zeigt, funktioniert so nicht.

Noch einmal so eine sehr gewagte Aussage von dir!
Du glaubst schlauer zu sein als Leute, die ihr Handwerk (tatsächlich) verstehen.
 

Stromquelle am HUB-Kanal:
JEDER HUB-Kanal, also jede einzelne Buchse, stellt in seiner Grundkonfiguration einen Strom von 100 bzw. 150mA zur Verfügung.
DIESE 100mA Obergrenze ist klar als max. definiert, mehr darf es nicht sein. Diese Konstantstromquelle dient zur Messung
des Zustandes EINES devices JE Kanal und wird vom OS als auch BIOS so vorausgesetzt und auch so verwendet. Das erfolgt bei der
sogenannten Enumeration. Diese Definition von MAX. der 100mA wird oft auch den 500mA angedichtet. Das stimmt so aber nicht.

Konstantstromquelle ist schon einmal völliger Blödsinn, aber du kennst ja den Unterschied nicht.
Die 150 mA gibt es in der USB-Spezifikation tatsächlich.
Da hast du offensichtlich mal irgendwo etwas aufgeschnappt, das du jetzt völlig durcheinander wirfst.
 

Enumeration (simple Erklärung ohne Protokollierung):
Die Enumeration, die auch das BIOS beherrscht (sonst gäbe es ja keine Erkennung von devices beim Bootprozess), setzt eine strikte
Trennung der Stromquellen je Kanal voraus. Die Erkennung eines devices erfolgt auf Grund von pull-ups am USB-Datenbus. Wird ein
device erkannt, (dafür müssen die 100mA ausreichen), wird der Strom erhöht (500mA oder auch MEHR). Dann wird die Spannung gemessen
und bei zu geringer Spannung (Überstrom), wird nur dieser eine Kanal wieder auf 100mA reduziert oder ganz abgeschalten. Kein
anderes device an diesem HUB darf durch dieses fehlerhafte device beeinflusst werden. Das ist Standard und kann nicht einfach durch
eine Billiglösung mit einer gemeinsamen Konstantstromquelle für mehrere Buchsen umgangen werden. Mit einer Schaltung, wie sie von
dir und Heise angenommen wird, würde der gesamte Enumerationsprozess für die device Erkennung nicht mehr funktionieren. Diese
Vergemeinerung der Stromquelle würde Interferenzen zwischen allen Kanälen verursachen. Jeder Spannungseinbruch, verursacht durch ein
device wegen kurzzeitiger Stromspitzen z.B. bei Einschalteprozessen (ERLAUBTE Toleranz an EINEM USB-Kanal), würde alle anderen
devices wie keyboard oder mouse am selben HUB wegen angeblichem Überstrom abschalten, weil die gemeinsame Konstantstromquelle an
allen devices den erlaubten Spannungswert unterschreiten würde. Eine solche Spezialschaltung traue ich nicht einmal den Chinesen
zu. Dein anderer Hinweis, dass die Konstantstromquellen der Ausgangsstufen überbrückt werden und so der Strom nur noch vom PS
begrenzt wird, ist wenig wahrscheinlich. Es müsste direkt an der USB-Buchse gelötet werden und es käme zu genau dem Effekt, wie von
Heise beschrieben. Parasitäre Ströme zwischen Kanal-Ausgangsdriver und PS würden den HUB auf Dauer wegen erhöhtem Stromfluss zerstören.

Tja. Da hast du mal etwas über den U.S.Bus gelernt, besitzt aber keinerlei (brauchbare) elektrotechnischen Grundlagen.
Zudem habe ich nicht den Begriff Konstantstromquelle benutzt.
 

... wie z.B. leider auch bei billigen USB3-PCI-Express Steckkarten — nur durch das Netzteil begrenzt

Wie das bei USB3-PCI-Express Steckkarten ist, das kann ich nicht beurteilen. Sollten die aber einen eigenen USB-Hub auf ihrer Karte
verbaut haben, dann kann ich mir eine solche Schaltung nicht vorstellen, weil sie weder Einsparung noch Sinn ergeben.
Im Gegenteil, es wäre ein sinnloser Mehraufwand mit Schadensgarantie.

Jeder USB-Controller besitzt auch einen internen Root Hub.
Wie viele Ports dann am IC bereitgestellt werden, hängt vom Design ab, da dann auch mehr Pins vorhanden sein müssen und das IC daher größer wird. Beispiel: NEC Renesas µPD 720202 und µPD 720201.

Und du irrst dich: Es ist für den Hersteller ein sinnvoller Minderaufwand mit Schadensgarantie für den Endkunden, wenn Bauteile weggelassen werden.
 

Normalerweise muss jedem USB-Gerät, das mehr als 500 mA Strom benötigt, ein eigenes Netzteil gewidmet sein.

Das ist natürlich richtig. Die 500mA müssen laut Standard z.B. 2.0 an ein erfolgreich enumeriertes device geliefert werden.
Mehr kann sein, darf aber vom Entwickler eines devices nicht angenommen werden. Es gibt HUB-Controller, deren Ausgangsdriver mit
800mA angegeben sind.

Den „HUB-Controller“ zeigst du mir mal bitte. Am besten gleich mit Anwendungsbeispiel des Herstellers.
 

[…]

Vorbildlich sind hier Computer der Firma Apple Inc.
Nimmt ein USB-Gerät zu viel Strom auf, wird es dauerhaft (per Schalttransitoren) vom Rechner getrennt und es erscheint eine Fehlermeldung auf dem Bildschirm, dass dieses „genau bezeichnete“ Gerät zu viel Strom zieht, also möglicherweise einen Defekt hat und deswegen deaktiviert wurde.
Qualität hat aber ihren Preis.

Auch Apple hat nichts Neues erfunden, die verbauen auch nur die am Markt erhältlichen Controller für Hubs, genau so wie alle
anderen. Und alle diese Controller arbeiten nach dem Prinzip, wie oben vereinfacht beschrieben, weil das BIOS damit können muß.
Das gilt für alle, auch für Apple.

Nein. Du irrst dich vollkommen!
Apple Inc. kann seine Rechner nebst Zubehör deswegen spezifikationskonform bauen, weil die Kunden bereit sind, den hohen Preis für die Produkte zu bezahlen.

Bei den „IBM-kompatiblen“ gibt es einfach zu viele Hersteller, die mit Kampfpreisen und dem Weglassen selbst kleiner Bauteile im Centbereich auf den Markt drängen, und es gibt sehr viele „Geiz ist Geil“ Käufer und Verkäufer.

—
 

Rein gefühlsmäßig halte ich einen Defekt des Geräts für wahrscheinlich

Wenn die externe Festplatte unter openSUSE 12.3 (Kernel 3.7) funktioniert, ist sie nicht defekt.
Unter Linux muss man bei Einkäufen immer die Hardware im Auge behalten. Deswegen fiel meine persönliche Wahl auf ASMedia.