Pages: [1] 2 3 ... 7 
|
 |
|
|
Author
|
Topic: [gelöst] USB Treiber Probleme ab v2.7.83 - Berichte erbeten!! (Read 12657 times)
|
|
hb9bdm
schon länger dabei
 Offline
Posts: 64
Ich liebe dieses Forum!
|
 |
[gelöst] USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« on: 12. February 2018, 08:36:34 »
|
|
Hallo Freunde
Seit Längerem erfreue ich mich einer gut funktionierenden Firmware und das bis zur Version 2.7.82 (Mit Grossschrift). Ab Version 2.7.83 sehe ich wieder das schon zweimal gehabte Problem beim laden der Treiber für Cat (Comport) und der korrekten Installation der Audio Treibern über USB . Das wie schon zweimal gehabt. Grund: Speicher oder was auch immer. Also genau wieder dasselbe Übel. Lässt sich da vielleicht etwas machen, denn ich liebe die neue Grossschrift Frequenzanzeige? Für Tests stehe ich gerne zur Verfügung.
73 Chris
|
| « Last Edit: 27. February 2018, 05:25:27 by DL8EBD » |
 Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:USB Treiber Probleme ab v2.7.83
« Reply #1 on: 12. February 2018, 14:12:17 »
|
|
Das ist garantiert wieder ein "out-of-RAM"...
Bitte schreib einen Issue-Bericht auf GitHub - dann sehen das die Programmierer schneller.
EDIT:
Bitte probiert doch mit einer der Versionen ab 2.7.83 bis einschließlich der 2.9.2 mit aus, ob CAT und Audio bei euch noch laufen. Interessant ist vor Allem, was für ein Betriebssystem und was für eine Version ihr benutzt. Wir hatten das schon mal verglichen - die USB-Enumerierung läuft ohne sichtbare Veränderung weiter, aber bei bestimmten (??) Windows-Versionen geht dann nichts mehr - warum auch immer. Ich wrde gerne wissen, welche betroffen sind und welche nicht.
Interessant ist auch, dass ich das mit meinen mcHFs und meinem Linux-System wieder mit keinem Programm reproduzieren kann. Bei mir läuft alles wie vorher, keine Einstellungen sind anders, CAT und Audio funktionieren einfach out-of-the-box.
vy 73
Andreas
|
| « Last Edit: 12. February 2018, 18:01:19 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hb9bdm
schon länger dabei
Offline
Posts: 64
Ich liebe dieses Forum!
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #2 on: 16. February 2018, 08:53:55 »
|
|
Danke Andreas,
die letzte Version v2.9.6 arbeitet wieder normal
73 Chris
|
|
Logged
|
|
|
|
|
|
hb9bdm
schon länger dabei
Offline
Posts: 64
Ich liebe dieses Forum!
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #4 on: 16. February 2018, 14:26:24 »
|
|
Das glaube ich auch nicht, dass niemand ausser mir Cat benutzt, aber ich benutzte hier seit laengerem diverse Digi Programme, die ich immer gleich aufstarte, und da zeigte es mir sofort den Treiber Fehler. Auch wenn ich der Einzige sein sollt, es konnte diesmal wieder behoben werden und ich komme in den Genuss der Grossschrift und des gut funktionierenden Noisereduction.
Danke Andreas
|
|
Logged
|
|
|
|
|
|
hb9bdm
schon länger dabei
Offline
Posts: 64
Ich liebe dieses Forum!
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #6 on: 17. February 2018, 00:07:57 »
|
|
Ich verwende ein normales Windos10 32. auf einem Supermicro C7 Board
Digi Programme sind: Mixw2, Fldigi, Multipsk und Ham Radio Delux.
Bei alles diesen Programmen verwende ich USB Connect.
Bei eingestecktem, verbundenem mcHF - zum Rechner mit USB Kabel
werden beim Missverhalten die Audioports oder Comport Nummer, falsch gesetzt. Das ist nicht der Fall wenn es wie jetzt wieder, ich mit v2.9.6 (Mit Grossschrift) arbeite, dann laeuft alles richtig. Bei Missverhalten, sehe ich zwar im Geraete Manager das Port und auch die Audio in/out, aber sie werden nicht richtig angenommen. Thats a fact, und den hatte ich jetzt das dritte mal. Was Du, ihr, dann machtet dass es wieder klappte, weiss ich nicht? Erklaere es mir.
73 Chris
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #7 on: 17. February 2018, 07:39:50 »
|
|
Hallo Chris,
kannst du bitte mal für eine der problematischen Versionen, also eine Version, bei der das Problem sicher auftrat, den entsprechenden Small Build flashen (den für die MCU < 512K) und berichten, ob das auch beim small build nicht funktioniert.
73
Danilo
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #8 on: 17. February 2018, 08:44:55 »
|
|
Ich rate mal, dass es an deinem Micro C7 Board liegt. Ich habe mal versucht, auf so einem "tollen neuen Gerät" ein Linux System zu installieren. Ganz davon abgesehen, dass es mir das UEFI mit dem nicht abschaltbaren security Boot fast unmöglich gemacht hat da ein Linux draufzukriegen lief nach etlichen Versuchen auch nur ein speziell gepatchtes Ubuntu. Die Hardware ist dort (gelinde gesagt) sehr eigenwillig und hat mit den normalen Kerneltreibern nicht richtig funktioniert. Es hat zwar funktioniert - aber eben nicht richtig. Hat sich aufgehängt, war an Stellen zäh, wenn ich was ganz anderes aktiviert habe (z.B. hakte die Grafik nach dem Einstecken eines USB-Sticks).
Mich würde wirklich brennend interessieren, ob mit den benannten Versionen, die bei Dir den Bug haben, auch andere mit Windows-Systemen einen Fehler reproduzieren können. Das ist natürlich alles kein Beweis - alles was ich geschrieben habe ist reines Bauchgefühl - und die negativen Erfahrungen mit diesen modernen Tabs kommen aus meinem Berufsalltag.
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #9 on: 17. February 2018, 08:50:24 »
|
|
Hi Andreas,
wenn es dass C7 board ist, warum ändern dann unterschiedliche UHSDR Firmware releases dass Verhalten, obwohl in keiner von den Releases Änderung am CAT gemacht wurden? Am C7 Board und Windows 10 sind ja keine Veränderungen vorgenommen worden.
Also ich würde da schon eher der das Problem liegt auf Seiten des Speicher beim mcHF sei. Wir schauen mal, was der Test mit dem Small Build bringt, der ja nicht nur weniger Flashbedarf sondern eben auch den RAM Bedarf von FreeDV nicht hat. Damit ist hier auch mehr "Platz".
73
Danilo
|
|
Logged
|
|
|
|
hb9bdm
schon länger dabei
Offline
Posts: 64
Ich liebe dieses Forum!
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #10 on: 17. February 2018, 09:11:46 »
|
|
Hallo
Andeas,such doch den Fehler nicht immer bei mir. Ich berichte nur Tatsachen und kann Dir sagen, dass es mit anders Pc's dasselbe ist, es auch nicht funktioniert, ich habe 5 Syteme hier. Ihr habt mich mal gefragt euch zu melden wenn es wieder auftaucht, das habe ich gemacht. Dann wurde es wieder behoben, wie? Also!
Hallo Danilo
Du hast die richtigen Fragen gestellt. Irgendwie hanegt es mit der Speichegroesse zusammen. Ich stellet fest das ich ab FW v2.7.85 und spaeter das alte Treiber Problem wie vorgaengig beschrieben wieder auftrat, und zwar nur mit dem grossen File Size 464Kb. Dann versuchte ich es mit der 512 Version, also kleinern File. Das funktionierte OK.
Das ging dann so bis ich die Version v2.9.6 (Grossen File) versuchte. Bingo es war wieder in Ordnung. Aber File Size jetzt 451KB anstatt 464Kb. Die 512 Versionen gingen immer auch auf einem mcHF mit nur 512KB Flash Size.
Der Problem zeigt sich immer so, dass voreingestellte Werte des Comports und der Audio Adressen nicht mehre richtig eingetragen werden, was bei den gut funktionierenden Versionen nicht der Fall ist.
Macht es noch Sinn, dass ich weiter Berichte, wenn der schwarze Peter immer mir zugeschoben wird, aber dann das Problem doch irgebwie geloest wurde.
Danke Danilo
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #11 on: 17. February 2018, 09:31:52 »
|
|
Es gibt keine "schwarzen Peter" - nur Ursachen und Wirkungen.
Und da alle Versionen bei mir laufen, möchte ich einfach nur die Ursachen verstehen. Chris, würdest Du dabei helfen?
Du hattest das ja schon mal getan indem wir unsere USB Descriptoren verglichen haben. Ich meine mit lsusb ausgelesen, Du deine mit einem Windows-Tool. Ergebnis: bei beiden PCs exakt dasselbe.
Woran liegt es also, dass es auf dem einen PC läuft und auf einem anderen nicht - wobei bei beiden mcHFs der gleiche knappe Speicher vorliegt???
Das würde ich gerne verstehen! Und auch, warum sich sonst wirklich noch NIEMAND gemeldet hat, der das ebenfalls beobachtet hat.
EDIT:
Meine erste Vermutung ist und war, dass es ein Betriebssystem - spezifisches Verhalten ist. Das ließe sich ganz leicht feststellen - aber nicht von mir, da ich keinen einzigen PC mit Windows besitze. Bislang weder Bestätigungen, dass es mit einem anderen Windows-PC läuft oder eben auch nicht.
@Danilo:
Meine "Verdacht ins Blaue" ist dass sich durch den knapper werdenden Speicher das Timing verändert. Die Hardware anderer Windows-PCs oder Versionen können das genauso wie Linux auffangen - das Gerät von Chris nicht. Das kann durchaus ein Hardwareproblem sein. Es ist auch möglich, dass das Timing unseres USB-Ports dann out-of-specs ist, aber eben auf fast allen Geräten noch als korrekt erkannt wird.
Wobei der letzte Post von Chris, dass es bei ihm auf fünf PCs auftrat, diese Vermutung wieder über den Haufen wirft. Und ein noch größeres Fragezeichen aufleuchten lässt: Warum tritt es bei einem bei 5 PCs auf und sonst hat diesen Bug noch niemand gehabt?
vy 73
Andreas
|
| « Last Edit: 17. February 2018, 09:43:13 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #12 on: 17. February 2018, 10:10:56 »
|
|
Hallo Andreas,
@Danilo:
Meine "Verdacht ins Blaue" ist dass sich durch den knapper werdenden Speicher das Timing verändert. Die Hardware anderer Windows-Maschinen oder Versionen können das genauso wie Linux auffangen - das Gerät con Chris nicht. Das kann durchaus ein Hardwareproblem sein. Es ist auch möglich, dass das Timing unseres USB-Ports dann out-of-specs ist, aber eben auf fast allen Geräten noch als korrekt erkannt wird.
|
|
UHSDR: Das Zeitverhalten der Firmware verändert sich nicht, wenn der RAM Speicher knapper wird, es ist davon völlig unabhängig. Diese Theorie bringt uns nicht weiter.
Natürlich ist bei einem Multitaskingsystem wie Windows oder Linux das Zeitverhalten des USB Stacks variabel, und dadurch ergeben sich auch leicht andere Abläufe im UHSDR, aber wir hatten es hier ja mit einem systematisch, reproduzierbaren Fehler zu tun, der über die UHSDR Releases auftritt oder nicht, deswegen gehe ich erstmal nicht von einer Problemursache(!) auf Windows-Seite aus (wobei die Nutzung von Windows schon eine Rolle beim Auftreten des Fehlers haben kann, die eigentliche Ursache ist Windows aber nicht).
Wenn also der Fehler bei einer Firmware mit kleinerem RAM Bedarf (die Small-Builds brauchen nicht nur weniger Flash sondern belegen auch ca. 40k weniger RAM mit Daten, wg. Nichtnutzung FreeDV) nicht auftritt, bei einer ansonsten identischen Release mit FreeDV aber schon, liegt der Verdacht nahe, dass der Füllgrad des RAMs eine Rolle spielt.
Eine (!) mögliche Erklärung:
Hier kommt zum Tragen, wie der Speicher verwendet wird. In dem betreffenden RAM Bereich wird eine bestimmte Menge Speicher durch Daten belegt, und zwar vom Anfang des Bereichs bis zu einem bestimmten Punkt. Dieser Punkt wird durch den verwendeten Programmcode (globale und statische Daten plus über malloc belegte Daten bestimmt). Am Ende liegt übrigens der FreeDV Speicher (da dynamisch nach dem Programmstart belegt). Vom Ende dieses RAM-Bereichs her kommt der Stack, auf dem temporär je nach aufrufenen Funktionen zusätzlich Speicher belegt wird. Wenn dieser Stackbereich in den anderen Bereich reinwächst (oder umgekehrt), dann kommt es zur Zerstörung von Daten des Stacks, das kann komische Folgen haben. Die Stackbelegung ist hochdynamisch und daher durchaus zeitabhängig, d.h. je nach dem z.B. wann exakt der PC seine USB Kommandos schickt, kann bei 2 verschiedenen Systeme eine Überlappung auftreten oder nicht, oder keine sichtbaren Folgen haben.
Bisher wurde dieses Phänomen nur von wenigen beobachtet, aber alle Maschinen AFAIR 192k Maschinen, bei denen die Gefahr der Überlappung sehr viel höher ist, da wir hier fast 100% Auslastung des Speichers haben. Als ich den FreeDV gemacht habe, sind mir solche Effekt sehr wohl aufgefallen und ich konnte sie nachweisen durch Inspektion des Speichers mit dem ST-Link.
Und wenn wir uns die Unterschiede in der Speicherbelegung der Versionen anschauen, und das mit den Versionsnummern korrelieren, die Chris uns geliefert hat, glaube ich zu erkennen, das wir dort immer Sprünge nach oben in der Auslastung hatten und durch Reduktion die Sache wieder in Griff bekommen. Das ist schlecht, hängt aber mit der RAM Knappheit zusammen.
Eine einfache Lösung dafür gibt es nicht. Würden wir allen Speicher statisch belegen (und damit die Stacknutzung minimieren), würden wir soviel Speicher belegen, das wir nicht mit 192k auskommen. Wir könnten natürlich permanent prüfen, ob eine Überlappung auftritt. Da der Prozessor uns aber nicht freiwillig verrät, was der maximal Wert seinen Stacks war, ist das praktisch so nicht umsetzbar. Was man machen könnte, ist eine Schutzzone zwischen Stack und Speicher zu legen (ein sogenanntes "Canary"-Konzept, vom Kanarienvogel, der früher in Bergwerken zum Erkennen von gefährlichen Gasen eingesetzt wurde). Damit können wir erkennen, ob der Stack in diesen Bereich vorgedrungen ist. Das werde ich mal andenken.
Aber es gibt da noch viele andere mögliche Ursachen, die aus Programmierfehlern resultieren könnten.
73
Danilo
|
|
Logged
|
|
|
|
hb9bdm
schon länger dabei
Offline
Posts: 64
Ich liebe dieses Forum!
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #13 on: 17. February 2018, 10:24:57 »
|
|
Mir muss niemand helfen, die neueste FW v2.9.6 laufen nun wieder mit grossem oder kleinen Filesize. Bei mir ist der mcHF ein Arbeitgeraet, was ueber USB mit dem Rechner verbunden ist. Wenn dann aber bei einer neu geladenen FW es nicht mehr funktioniert, schaue ich genauer hin. Immer zuerst bei mir, eben auch mit auf anderen Rechnern und wenn sich dann das gleiche Problem zeigt, gelange ich an euch. Einfach weil die vorgegeben Konfiguration die bis jetzt anstandslos lief, nicht mehr ging. Ob andere das Probelm nicht haben bezweifle ich. Aber die Voraussetzungen sollten identisch sein, naemlich als Arbeitsgeraet nicht als Testversuch. Bei mir befinden sich 6 verschiedene SDR Transceiver, inkl. dem Icom7300, der sich fast identisch aufsetzen laesst wie der mcHF, aber immer mit derselben FW.
Nur nochmal, eine Frage? Warum ging es mit v2.7.85 nicht Filesize 464kb, aber dann wieder mit v2.9.6 bestens, Filesize 451kb. Das ist nur eine Frage.
Es geht mir auch nicht darum wer recht hat oder nicht, sonder um wiederholbare Tatsachen, auf verschiedenen Rechnern. Ich hatte mal ein aehnliches Probelm mit einem renomierten SDR Trasnceiver Hersteller, wo ich auch als einziger eine Problem fand oder erkannte.
Chris
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
« Reply #14 on: 17. February 2018, 10:39:40 »
|
|
Das hat nichts mit dem Flash zu tun (oder mit der Filesize, die Du sehen kannst), sondern mit der Auslastung des internen RAMs der MCU des mcHF. Die dort vorhandenen 192KB sind nahezu aufgebraucht, wenn man FreeDV mit im Boot hat. Bei der für die kleinen MCU gebauten Firmware ist FreeDV nicht mit dabei - deswegen ist der RAM-Verbrauch niedriger.
Wie Danilo schon sagte, kann man den RAM-Verbrauch nicht 100% sicher bestimmen. Es gibt Dinge in der MCU, die werden dynamisch belegt, wie z.B. der Stack. Da kann es dann schon mal sein, dass, wenn irgendwas in irgendeinem Timing anders ist, der Stack unterschiedlich groß ist. Und dieser Unterschied von ein paar Bytes kann über funktionieren und nichtfunktionieren entscheiden.
Es kann auf jeden Fall keine generelle Überlappung sein - dann dürfte es auch unter Linux nicht mehr funktionieren. Es muss irgendwas sein, was im Zusammenspiel mit (EDIT: deiner Konfiguration von/mit) Windows auftritt.
Klar: wenn wir genügend RAM frei haben ist das Problem weg. Aber wir werden bei der 192KB MCU niemals mehr "genügend RAM" (EDIT: nach dem Motto: "don't worry be happy") frei haben - wir müssen mit dem Leben, was da ist. Also muss man auch die andere Seite anschauen. Vielleicht liegt es ja an einer bestimmten Windows-Version? Oder an einer bestimmten STM- oder Audio-Treiberversion?
Wir brauchen mehr Berichte, ob und wenn unter welchen Kombinationen der Fehler auftritt! Durchaus möglich, dass er weg wäre, wennn Du eine andere Treiberversion wählst. ABER: das sollte man erst tun, wenn da auch genügend Feedback hintersteht, dass das was bringt.
Wir haben einfach NULL Rückmeldungen (außer deiner) zu diesem Problem - und damit ist ein eventueller Workaround nicht zusammenzunageln.
EDIT:
Und dass das mit der 6er-Version wieder ging lag daran, dass Danilo in Sachen RAM-Verbrauch unabhängig von deiner Fehlermeldung den uralt-Code von Chris/Clint, aber auch unseren nach zu großzügig belegtem Speicher durchforstet hat und ein paar Dinge verbessert hat. Dadurch haben wir wieder wenige Kilobyte frei. Aber selbst so ein Feature wie ein größerer Font verschlingen auch RAM (im Betrieb). Wir kratzen an dieser Grenze schon länger.
vy 73
Andreas
|
| « Last Edit: 17. February 2018, 11:17:02 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
Pages: [1] 2 3 ... 7 
|
|
|
|
|
|
|
