sschultewolter
Goto Top

Störungen mit USB Hub unter Windows 8.1

Hallo,

ich habe mit einem D-Link 7-Port-Hub derzeit große Probleme. Die Geräte werden an dem Gerät erkannt, u.a. Logitech Unify, Diamex AVR ISP Programmer, ...
Jedoch bekomme ich dauerhaft, ca alle 5-10 Sekunden das Geräusch, dass ein USB Gerät ein und ausgesteckt wurde.
Das ganze passiert mit einen GA-H77N-WIFI(http://www.gigabyte.de/products/product-page.aspx?pid=4338#ov) unter Windows 8.1 Pro x64.
Als Referenz habe ich dieses auch mit einem Samsung RC730 Notebook und Windows 7 Profession x64 getestet. Dort gab es keinerlei Probleme.
Ich hatte zwischenzeitig auf einer Festplatte Linux (Mint MATE Edt). Dort traten diese Probleme nicht auf.

Somit liegt meine Vermutung nahe, dass Windows 8.1 hier große Probleme hat. Ich habe auch bereits das System neu aufgesetzt, nach dem ich ein Backup gemacht habe. Dadurch lies es nicht beheben.
Das Gerät wird sowohl unter Windows 8.1 sowie auch unter Windows 7 als "Generischer USB-Hub" erkannt.

Unter der Windows Ereignisanzeige weißt nichts auf einen Fehler hin. Habe diesen gerade noch mal geleert, in der Hoffnung dass dort doch noch was auftauscht.


Gruß Stefan

Content-ID: 251003

Url: https://administrator.de/forum/stoerungen-mit-usb-hub-unter-windows-8-1-251003.html

Ausgedruckt am: 24.12.2024 um 13:12 Uhr

chiefteddy
chiefteddy 05.10.2014 um 21:12:25 Uhr
Goto Top
Hallo, tritt das Problem auch auf, wenn kein Gerät am USB-Hub angeschlossen ist? Und was verstehst Du under "Geräusch"?

Wir der USB-Hub durch ein eigenes Netzteil mit Storm versorgt? (Hier gibt es häufig Probleme --> Artikel in einer der letzten ct)

Jürgen
sschultewolter
sschultewolter 05.10.2014 um 21:27:29 Uhr
Goto Top
Hallo Jürgen,

danke schon einmal für die Rückantwort.

Rechner1 : Mini-ITX Board Gigabyte Windows 8.1
Rechner2: Notebook mit Windows 7


Das Problem tritt an Rechner1 immer auf. Ob das Netzteil angeschlossen ist, oder nicht, spielt keine Rolle. Das gleiche gilt auch für angeschlossene Geräte. Steckt kein Gerät in den Ports, tritt dieses Problem auch auf. Das ganze geht an Rechner2 ohne Probleme.

Zum Geräusch, es ist dieser typische Windows Sound für die Gerätetrennung/Windows-Hardware entfenen.

Habe es mit mir allen zur Verfügung stehenden USB-Kabeln versucht. Von 20cm - 2m länge, sowohl teure mit ordentischer Abschirmung und Ferritkernen sowie auch mit den billigen Beigaben der Hersteller.
chiefteddy
chiefteddy 05.10.2014 um 21:54:14 Uhr
Goto Top
Hallo;

tritt das Problem an allen USB-Ports des Boards auf?

Tritt der Fehler auch mit einem anderen Hub (anderer Hersteller) an diesem PC auf?

Jürgen

PS: Aktuelle Treiber für den OnBoard-USB-Hub (vom Chip-Hersteller) ?
sschultewolter
sschultewolter 05.10.2014 um 22:14:48 Uhr
Goto Top
Hallo Jürgen,

Problem tritt an allen USB Ports auf, die am Mainboard montiert sind. Einen anderen Hub habe ich nicht da. Den letzten hatte ich vor 1 Jahr weggeworfen da dieser nach vielen Jahren den Dienst aufgab.

Akteulle Treiber wurden installiert.


Ich habe es nun vermutlich im Griff bekommen, wobei mir immer noch nicht klar ist, woran es lag. Vermutlich taucht es wieder auf.

Habe alle Geräte, die nicht aktiv (-> ausgeblendet) sind, entfernt und den PC danach neugestartet. Nun kommt das "Dong" vorerst nicht mehr.

Eine Frage an die Herren, gibt es ein zuverlässiges Logfile, welches mir angibt, wann ein USB Device sich an oder abmeldet? Unter der Ereignisanzeige geschieht dieses nicht.
default-user
default-user 13.10.2014 um 21:06:22 Uhr
Goto Top
Hi Stefan!

Ich hab ein ziemlich ähnliches Problem in diesem neuen Thread beschrieben. Ich konnte die Probleme mit Ferritkernen auf jeweils beiden Zuleitungsenden verringern, aber noch nicht beheben können.

Mein Verdacht: Der USB-3-Hub liefert so viel HF-Störnebel, auch über alle USB-Anschlussleitungen, die an ihm eingesteckt werden, dass er viel besser entstört werden müsste. Zudem könnte es sein, dass ein USB-3-Hub, der durch Einstecken eines USB-2-Geräts zwar nach dem USB-2-Standard arbeitet (die Timings), jedoch die Flankensteilheit dieser Signale nach wie vor denen eines USB_3-Signals entsprechen. Und damit könnten manche USB-2-Geräte Probleme haben.

Ich habe gerade gelesen, dass du ebenfalls mit Ferritkernen experimentiert hast. Frage: Hast du die Kerne auf den jeweiligen Kabeln nur einseitig angebracht? Und wenn ja, eher an die dem Hub zugewandten Seite oder an der Geräteseite?

Frage 2: Hast du auch das Verbindungskabel zwischen USB-Hub und PC mit Ferriten gefiltert? Wenn ja, einseitig oder beidseitig?

Ich habe zunächst Ferritkerne an der Geräteseite angebracht, später dann auch direkt an Hub-Seite. Und heute habe ich das USB-3-Verbindungskabel zum Notebook beidseitig gefiltert. Jedes Mal stellte ich eine gewisse Verbesserung fest!

Noch was: Ferritkerne sind Mantelwellenfilter. Sie sollen HF-Ströme, die aufgrund des Skin-Effekts außen auf den Abschirmungen der Kabel entlang laufen, wegfiltern. Je straffer (ohne Spiel) sie auf dem Kabel drauf sitzen, desto besser wirken sie. Falls bei dir Luft zwischen Ferritkern und Kabel geblieben ist, könnte dies erklären, dass du damit wenig Erfolg hattest.

Beste Grüße
Clemens
sschultewolter
sschultewolter 14.10.2014 um 02:23:40 Uhr
Goto Top
Hallo Clemens. Ich habe am Gehäuse 2 USB3.0 Buchsen, die über den 19(20) poligen Stecker mit dem Mainboard verbunden sind. An denen tut der Hub überhaupt nicht. Auch machen einige andere Geräte dort immer wieder Probleme vorallem mit Sandisk USB Sticks. Hingegen funktionieren die Unifying Sticks (Logitech Maus/Tastatur) daran wunderbar.

Zu den Kabeln mit Ferrit Kern. Der Ferrit ist im Kabel mit eingearbeitet und direkt an der Buchse des PCs. Das brachte aber nicht den Erfolg. Habe es aber auch mir Ferriten versucht, die man nachträgtlich einbauen kann.

Das komische, unter Linux Mint gab es keine Probleme.
default-user
default-user 14.10.2014 um 12:36:46 Uhr
Goto Top
Hallo Stefan!
Dann würde der Ferrit evtl. noch Sinn machen, wenn er auf der Verbindungsleitung zwischen Mainboard und USB-Buchse angebracht wird, falls hierfür ein abgeschirmtes Kabel zum Einsatz kommt.

Total krass aber finde ich, dass die gleiche Konfiguration unter Linux Mint einwandfrei funktionieren soll!!! Weil dies würde ja daruf hindeuten, dass das Übertragungsprotokoll, das der USB-3Treiber unter Windows veranstaltet, im Timing ziemlich schräg läuft und unter Linux der Treiber eben besser programmiert ist!

Gegen blöde Treiber aber kann man kaum was machen! Es gibt auch keine Parameter, die man am Treiber einstelln kann.
Bei mir sind immer die Windows-7 USB-Treiber (=Microsoft) aktiv. Auch der Hub brachte keine eigenen Treiber mit. In 2012 gab es wohl mal ein Firmware-Update, das man in den (VIA) Chip des USB-Hub einspielen konnte.

Ich werde nun bei mir die Strategie verfolgen, den Hub auseinander zu nehmen und HF-technisch zu optimieren (Abschirmungen, bessere Masseverbindungen - besonders zu den Buchsen usw.

Beste Grüße
Clemens
sschultewolter
sschultewolter 14.10.2014 um 23:29:23 Uhr
Goto Top
Kannst ja Rückmeldung geben, ob sich was verbessert.

Habe soweit nun den Windows Sound ausgeschaltet. Funktion ist gegeben, aber sinning ist sowas nicht. Treiber gab es leider keine dabei. DLink bietet keine Treiber selber an, es werden die Standard M$ Treiber "empfohlen":
default-user
default-user 14.10.2014 um 23:52:23 Uhr
Goto Top
Hi Stefan!

Ich war soeben wieder in meiner Praxis und habe nun die letzte noch einseitig mit Ferritkern geblockte Leitung (die zum Scanner) ausgetauscht gegen eine mit Ferrit an beiden Enden. Jetzt laufen die Druckaufträge mit nur wenig Rucklern bei der Datenübertragung durch. Damit war die Zeit, bis der Druck beginnt, immer noch verzögert. Kein Druckauftrag blieb hängen.

Jetzt hab ich gerade den Hub geöffnet und untersucht. Der ist mechanisch und elektrisch eigentlich sauber aufgebaut. Sogar die Schutzdiode, die den Rückfluss der Spannungsversorgung zurück in den an den Hub angeschlossenen PC war eingebaut.

Ich fand nur einen Ansatzpunkt an den vier Buchsen des Hub, die für die anzuschließenden Geräte da sind: Deren Versorgungsspannung ist einfach von Buchse zu Buchse durchgeschleift ohne irgendwelche HF-Entkopplung! Das halte ich für einen Kunstfehler. Daher habe ich nun an jede USB-Buchse über die Versorgungsspannungsanschlüsse einen Keramik-Kondensator 1nF und parallel dazu einen von 100nF gelötet. (alles SMD-Technik). Bedrahtete Bauteile sind hier ungeeignet.

Morgen teste ich mal, ob nun überhaupt noch Störungen auftreten und schreibe dann hier wieder.

Generell zeigen meine Erfahrungen, dass mit hoher Wahrscheinlichkeit vagabundierende Hochfrequenz die Ursache dieser Störungen darstellt. Speziell bei meinem Hub der Firma LogiLink scheinen meine Maßnahmen Erfolg zu bringen. Bei USB-3 Hubs anderer Hersteller oder anderer Bauformen können ganz andere Probleme auftreten und evtl. nutzen dann meine Maßnahmen dort nicht.

Inzwischen fand ich im Internet mehrere Hinweise, dass USB-3-Hubs bis zum heutigen Tag immer noch nicht eindeutig standardisiert sind, sodass jeder Hersteller letztlich sein eigenes Süppchen kochen kann. Inkompatibilitäten sind dann natürlich zu erwarten!
Für dich könnte das bedeuten, dass du evtl. den LogiLink-Hub kaufst, den ich hier "in Bearbeitung" habe, denn dann weißt du in etwa, was du erwarten kannst.

Beste Grüße
Clemens

PS: Wieso hast du den Windows-Sound abgeschaltet? Was hat das mit USB-3 zu tun? - Damit keine Störungsmeldungen betr. USB von Windows akustisch untermalt werden?
sschultewolter
sschultewolter 15.10.2014 um 20:13:05 Uhr
Goto Top
Wie kommst du ganze Zeit darauf, dass ich einen USB3.0 USB Hub habe? ;)

http://www.amazon.de/D-Link-DUB-H7-7xUSB-A-1xUSB-B-Stromversorgung/dp/B ...

Ich habe den Ton für das Erkennen und abmelden neuer Geräte abgeschaltet. Weil dieser Ton alle paar Sekunden einen krank macht. Eine Lösung ist noch nicht in Sicht und ob die Kerkos bei meinem Teil den Erfolgt bringen ist fraglich.
Zur Not werde ich mich für ein anderes Modul entscheiden und den Dlink für nen RaspPi oder mein Notebook gebrauchen.

Problem ist, dass mein ITX-Rechner steht recht weit unterm Tisch. Komme da so nicht an die USB Anschluss ran.
Habe mir dafür den Hub auf den Tisch gelegt, da ich immer mal wieder eine größere Anzahl an USB Geräten anschließen muss. (AVR ISP Programmer, FTDI RS232 Wandler, Logik Analyser, etc).

Ich brauch auf dauer was zuverlässiges.
default-user
default-user 16.10.2014 um 10:08:17 Uhr
Goto Top
Hallo Stefan!

Gestern Abend war Test meines modifizierten Hub. Kein Druckauftrag hing sich mehr auf. Der Datentransfer zum Drucker stockte zwar immer wieder aber jeder Druckauftrag kam auch zum Ende und zum Druck. Das war eben vorher nicht so.

In der Summe kann ich aber nicht sagen, ob es nun eher die Kondensatoren gebracht haben oder eher die vielen Ferritringe.

Ich fand aber noch was heraus: Der Hub beinhaltet den Via-Chip VLC810. Der ist spezifiziert (und so stellt es VIA auch in seiner werbung heraus), dass er von USB 1.1 bis 3.0 alle Geräte gemischt antreiben kann. Im Chip sitzen im Prinzip je Ausgang 2 Hubs. Wird ein USB-2 Gerät erkannt, schaltet der Chip den Ausgang auf den USB-2-Modus um. Wird ein altes 1.1-Gerät erkannt, wird ebenfalls die Geschwindigkeit angepasst.

Im Tool USBDEVIEW fand ich nun, dass mein USB-Druckeranschluss als USB-1 Gerät aufgelistet ist. Ich dachte aber immer, mein Laserdrucker hätte USB 2.0.

Der Witz liegt evtl. nun darin, dass im USB-Hub eine Gerätepriorisierung im Datenverkehr stattfindet, sodass langsame Geräte auch zugleich eine niedrige Priorität erhalten. Wenn also mein Scanner alle paar Millisekunden ein Lebenszeichen sendet, dass er aktiv ist, könnte dies den Datenfluss einer Druckdatei zum Drucker kurz unterbrechen. Und weil der Druck-Spooler nicht mitbekommt, was da draußen auf den Anschlüssen vorgeht, meldet er halt einen Fehler.

In der Windows-Ereignisanziege steht dann:
EbpmonB CIOAccess::IOBufferingWrite - WritePort failed
LastError = 31

Die einzige Ähnlichkeit zu deinem Problem sehe ich darin, dass es bei mir genau so angefangen hat, wie bei dir: Dauernd wurden unbekannte USB-Geräte gemeldet, die es aber in Wirklichkeit nicht gab und auch ab und zu wurden der Druicker oder der Scanner als Problemgeräte gemeldet, funktionierten danach aber wieder, ohne Neustart usw.

Viel Glück!