Mac Mini MD387D/A: USB 3.0 Platte legt USB Ports lahm

E

Eratosthenes

Aktives Mitglied
Thread Starter
Dabei seit
23.10.2014
Beiträge
139
Reaktionspunkte
12
Hallo zusammen,

ich habe hier einen interessantes Effekt.

Mich würde interessieren, ob das jemand nachvollziehen kann:
Schliesse ich an meinen 2012er Mac Mini im Betrieb ein bestimmtes USB Gehäuse direkt an, funktionieren angeschlossene USB Devices, wie beispielsweise die Maus nicht mehr. Den Fehler habe ich bereits seit diversen OS-X Versionen, trotzdem ärgert er mich jedes Mal aufs Neue, wenn ich die Platte anschliesse. - Unvermittelt ausprobiert habe ich das mit verschiedenen Platten in diesem Gehäuse.

Die Platte wird gemounted und der Zugriff ist einwandfrei. Allerdings funktioniert die Maus nicht mehr. Der Fehler ist jederzeit nachvollziehbar, unabhängig davon welchen USB Port (vor- oder hinter der Maus) ich nutze. Boote ich das System neu, funktionieren alle USB Geräte einwandfrei.

Interessant: Schliesse ich die selbe Platte an einen passiven USB 3.0 Hub - also einen ohne zusätzliches Netzteil - der mit dem Mac Mini verbunden ist an, funktioniert alles einwandfrei. Ich kann sie also auch im Betrieb anschliessen u. entfernen...

An anderen Rechnern, Windows, Linux, andere Macs, funktioniert das Gehäuse absolut einwandfrei. Selbst angeschlossen am USB 2.0 Port, der nur 500mA liefert.

Hat jemand ein solches Verhalten schon mal gesehen?

Danke für die Info.

P.S.: Zur Platte bzw. zum USB Device
Inateck Generic USB Device
Prodkt ID: 0x2590
Hersteller ID: 0x2109 (VIA Labs, Inc)
Version: b.e1
 
Das wird ein Problem mit der Spannung beim Verbinden sein, so dass der interne USB-Hub abgeschaltet wird. So meine Vermutung zu dieser Fehlerbeschreibung.

Inateck ist ein guter Hersteller, ich würde ihn anschreiben, das sollte so natürlich nicht sein.
 
Hallo,

danke für die Info. Das habe ich auch gedacht. Allerdings würde ich dann vermuten, dass ich einen Eintrag in die Syslogs/Errorlogs bekomme. Das ist hier nicht der Fall.

Da das Gehäuse schon ziemlich alt ist und ich eh nichts mehr unternehmen kann, lohnt es vermutlich nicht, Inateck zu kontaktieren. Zumal das Gerät, ausser an dem Mac Mini seit >>1Jahr einwandfrei funktioniert...

@Inateck ist gut: Jep! Der Controller liefert >400MB/s lesend wie schreibend. Mein schnellstes USB Gehäuse!

Nachtrag: Was, wie geschrieben, interessant ist, ist, dass es absolut problemlos an einem USB Hub läuft!
P^2.S.: Bei Windows heisst die entsprechende Meldung übrigens: "Stromüberspannung auf USB-Hubanschluss". G*il übersetzt, gell?! - DAS war bestimmt ein Physiker. *lach
 
Oh, nichts in der Konsole ist wirklich ungewöhnlich. Im Systemprofil ist dann sicherlich auch alles wie immer. Ich würde es trotzdem so erklären :D. Wobei dieser Mini schon ein USB-Sensibelchen ist, finde ich. Im laufenden Betrieb USB 3.0 umstecken kann schon mal zu einem Schluckauf führen. Da ist der Schreck groß.

Musst Du wissen, ob es Dir zu alt ist. Ich bin immer dafür, gute Geräte möglichst lange zu nutzen.
 
  • Gefällt mir
Reaktionen: Eratosthenes
Solange ich kein schnelleres USB Device finde, werde ich dieses Gehäuse _SICHER_ für SSDs nutzen.

Mit dem Teil spiegelst Du 'ne aktuelle 250GB SATA SSD in ca. 600s, also 10min! Das musst Du mit einem anderen Controller erst mal schaffen.

Das BLOEDE ist halt nur, dass ich, wenn ich nicht dran denke, den USB Controler des Mac Minis jedes Mal auf's Neue wieder abschiesse... :(
 
Wieso kriegt der selbe Mac dann, bei angeschlossenem USB Hub keinen Schluckauf?

Nebenbei: Angeschlossen über diesen Hub kopiert der Mac eine 3GB Datei in deutlich unter 10s von der SSD auf die eigene Platte (Samsung 850, 500GB). Ein guter Wert, gell?
 
Weil es dann keinen Anlaufstrom gibt, der nur auftritt, wenn die Geräte verbunden werden. Ich hatte das Theater am Mini late 2009 mit einem anderen Gehäuse.
 
Ah ja. Das ist ein Argument.

Allerdings: Müsste der USB Controler dann nicht einen Error werfen, den ich im "log" wiederfinde?
 
Theoretisch ja, praktisch findest Du aber nichts :noplan:. Deshalb meine Frage nach der Anzeige im Systemprofil.
 
Die Sache wird übrigens noch lustiger:
Ich habe die Platte gerade, bei angeschlossenem HUB umgesteckt, also direkt am Mac Mini angeschlossen. => DAS funktioniert.

=> Hub abgezogen, Platte wieder angesteckt. => USB wieder wech... (STRANGE!!!)

(Das syslog bleibt latuernich leer!)

@Systemprofil: Was ist das? - Bin "Konsolen-Mensch" und nicht wirklich Mac-Anwender...

Nachtrag: Nicht ganz. Ich habe einen Dump gefunden:
Sep 13 20:21:13 steve symptomsd[230]: nw_interface_create_with_name netutil_ifname_to_ifindex(en4) failed, dumping backtrace:
[x86_64] libnetcore-583.50.1
0 libsystem_network.dylib 0x00007fff8e274de9 __nw_create_backtrace_string + 123
1 libsystem_network.dylib 0x00007fff8e2971f3 nw_interface_create_with_name + 179
2 Network 0x00007fff89da0edc -[NWInterface initWithInterfaceName:] + 120
3 SymptomEvaluator 0x00007fff974292fc config_callback + 874
4 SystemConfiguration 0x00007fff8d5d4faf rlsPerform + 184
5 SystemConfiguration 0x00007fff8d5e83ab __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52
6 libdispatch.dylib 0x00007fff889fd93d _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x00007fff889f240b _dispatch_client_callout + 8
8 libdispatch.dylib 0x00007fff889f703b _dispatch_queue_drain + 754
9 libdispatch.dylib 0x00007fff889fd707 _dispatch_queue_invoke + 549
10 libdispatch.dylib 0x00007fff889f5d53 _dispatch_root_queue_drain + 538
11 libdispatch.dylib 0x00007fff889f5b00 _dispatch_worker_thread3 + 91
12 libsystem_pthread.dylib 0x00007fff9c7814de _pthread_wqthread + 1129
13 libsystem_pthread.dylib 0x00007fff9c77f341 start_wqthread + 13
Sep 13 20:21:13 steve symptomsd[230]: -[NWInterface initWithInterfaceName:] nw_interface_create_with_name(en4) failed, dumping backtrace:
[x86_64] libnetcore-583.50.1
0 libsystem_network.dylib 0x00007fff8e274de9 __nw_create_backtrace_string + 123
1 Network 0x00007fff89da0f46 -[NWInterface initWithInterfaceName:] + 226
2 SymptomEvaluator 0x00007fff974292fc config_callback + 874
3 SystemConfiguration 0x00007fff8d5d4faf rlsPerform + 184
4 SystemConfiguration 0x00007fff8d5e83ab __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52
5 libdispatch.dylib 0x00007fff889fd93d _dispatch_call_block_and_release + 12
6 libdispatch.dylib 0x00007fff889f240b _dispatch_client_callout + 8
7 libdispatch.dylib 0x00007fff889f703b _dispatch_queue_drain + 754
8 libdispatch.dylib 0x00007fff889fd707 _dispatch_queue_invoke + 549
9 libdispatch.dylib 0x00007fff889f5d53 _dispatch_root_queue_drain + 538
10 libdispatch.dylib 0x00007fff889f5b00 _dispatch_worker_thread3 + 91
11 libsystem_pthread.dylib 0x00007fff9c7814de _pthread_wqthread + 1129
12 libsystem_pthread.dylib 0x00007fff9c77f341 start_wqthread + 13
Sep 13 20:21:13 steve symptomsd[230]: nw_interface_create_with_name netutil_ifname_to_ifindex(en4) failed, dumping backtrace:
[x86_64] libnetcore-583.50.1
0 libsystem_network.dylib 0x00007fff8e274de9 __nw_create_backtrace_string + 123
1 libsystem_network.dylib 0x00007fff8e2971f3 nw_interface_create_with_name + 179
2 Network 0x00007fff89da0edc -[NWInterface initWithInterfaceName:] + 120
3 SymptomEvaluator 0x00007fff974292fc config_callback + 874
4 SystemConfiguration 0x00007fff8d5d4faf rlsPerform + 184
5 SystemConfiguration 0x00007fff8d5e83ab __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52
6 libdispatch.dylib 0x00007fff889fd93d _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x00007fff889f240b _dispatch_client_callout + 8
8 libdispatch.dylib 0x00007fff889f703b _dispatch_queue_drain + 754
9 libdispatch.dylib 0x00007fff889fd707 _dispatch_queue_invoke + 549
10 libdispatch.dylib 0x00007fff889f5d53 _dispatch_root_queue_drain + 538
11 libdispatch.dylib 0x00007fff889f5b00 _dispatch_worker_thread3 + 91
12 libsystem_pthread.dylib 0x00007fff9c7814de _pthread_wqthread + 1129
13 libsystem_pthread.dylib 0x00007fff9c77f341 start_wqthread + 13
Sep 13 20:21:13 steve symptomsd[230]: -[NWInterface initWithInterfaceName:] nw_interface_create_with_name(en4) failed, dumping backtrace:
[x86_64] libnetcore-583.50.1
0 libsystem_network.dylib 0x00007fff8e274de9 __nw_create_backtrace_string + 123
1 Network 0x00007fff89da0f46 -[NWInterface initWithInterfaceName:] + 226
2 SymptomEvaluator 0x00007fff974292fc config_callback + 874
3 SystemConfiguration 0x00007fff8d5d4faf rlsPerform + 184
4 SystemConfiguration 0x00007fff8d5e83ab __SCDynamicStoreSetDispatchQueue_block_invoke_2 + 52
5 libdispatch.dylib 0x00007fff889fd93d _dispatch_call_block_and_release + 12
6 libdispatch.dylib 0x00007fff889f240b _dispatch_client_callout + 8
7 libdispatch.dylib 0x00007fff889f703b _dispatch_queue_drain + 754
8 libdispatch.dylib 0x00007fff889fd707 _dispatch_queue_invoke + 549
9 libdispatch.dylib 0x00007fff889f5d53 _dispatch_root_queue_drain + 538
10 libdispatch.dylib 0x00007fff889f5b00 _dispatch_worker_thread3 + 91
11 libsystem_pthread.dylib 0x00007fff9c7814de _pthread_wqthread + 1129
12 libsystem_pthread.dylib 0x00007fff9c77f341 start_wqthread + 13

Habe ihn noch nicht ganz gelesen. Weiss also noch nicht, ob das was mit USB zu tun hat...
 
Nicht strange, sondern genau passend. Der Hub fängt den Störstrom ab, wie ein Puffer.
 
Möglicherweise.

ERGEBNIS der Expedition: Das Device scheint Grenzwertig zu sein für den Mac Mini (nicht jedoch für USB2.0 an diversen Rechnern).

Interessant ist ein weiterer Eintrag im "Systembericht" zu diesem Device:
Verfügbare Stromstärke (mA): 1800
Sollte das System diesen Wert (2* so viel, wie USB 3.0 zulässt) irgendwie "auswerten", würde es ein Fehlverhalten sicher erklären...

Ich werde mich halt weiterhin darüber ärgern, dass sich der Mac Mini wech hängt, wenn ich das nächste Mal nicht dran denke, das Gerät unvermittelt anzuschliessen... ;-)

Zum Glück geht ja nichts wirklich kaputt dabei!!!

Dir vielen Dank für den "kompetenten Support" u. einen schönen Abend noch.
 
Zuletzt bearbeitet:
Eratosthenes schrieb:
Zum Glück geht ja nichts wirklich kaputt dabei!!!
Zum Vergrößern anklicken....
Bisher nicht, aber das kann ja noch kommen. Ich würde dieses Gerät austauschen und bis dahin nicht mehr nutzen. Warum der Eintrag in der Konsole fehlt, ist mir ein Rätsel, aber der Mini reagiert, der Hub wird abgeschaltet.

USB 2.0 ist für diese Stromstärken gar nicht ausgelegt, deswegen sollten selbst 2,5"-Platten ein Netzteil haben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten