ubuntuusers.de

kaekimaster schrieb:

praseodym schrieb:

Zeige

modinfo mt76x0u

Ja, das u am Ende ist natürlich wichtig. Meine Anweisung war da unvollständig.

kaekimaster@kaeki4:~$ modinfo mt76x0u
filename:       /lib/modules/5.0.2-050002-lowlatency/kernel/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0u.ko
license:        GPL
[…]
alias:          usb:v057Cp8502d*dc*dsc*dp*ic*isc*ip*in*
[…]
depends:        mt76x02-lib,mt76-usb,mt76,mac80211,mt76x0-common,mt76x02-usb

Kann es sein, dass die Dependencies "mt76x02-lib,mt76-usb,mt76,mac80211,mt76x0-common,mt76x02-usb" nicht vollständig erfüllt sind?

Jetzt ist es natürlich spannend, ob der Treiber beim Start des Kernel 5.0.2 mit eingestecktem AVM-WLAN-Stick auch vollständig geladen wird. Zeige:

uname -a
lsusb | grep 8502 ; echo $?
lsmod | grep -e mt76 -e 80211

Wenn der Stick nicht bei lsusb angezeigt wird: Stick ziehen, wieder einstecken und Befehle wiederholen.

Wenn die gefilterte Module-Liste unvollständig erscheint, diese Befehle ausprobieren:

sudo modprobe mt76x0u
lsmod | grep -e mt76 -e 80211

kB schrieb:

Jetzt ist es natürlich spannend, ob der Treiber beim Start des Kernel 5.0.2 mit eingestecktem AVM-WLAN-Stick auch vollständig geladen wird. Zeige:

uname -a
lsusb | grep 8502 ; echo $?
lsmod | grep -e mt76 -e 80211

kaekimaster@kaeki4:~$ uname -a
Linux kaeki4 5.0.2-050002-lowlatency #201903131832 SMP PREEMPT Wed Mar 13 22:43:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
kaekimaster@kaeki4:~$ lsusb | grep 8502 ; echo $?
Bus 001 Device 018: ID 057c:8502 AVM GmbH 
0
kaekimaster@kaeki4:~$ lsmod | grep -e mt76 -e 80211
mt76x0u                20480  0
mt76x0_common          45056  1 mt76x0u
mt76x02_usb            16384  1 mt76x0u
mt76_usb               32768  2 mt76x02_usb,mt76x0u
mt76x02_lib            61440  3 mt76x02_usb,mt76x0_common,mt76x0u
mt76                   49152  5 mt76_usb,mt76x02_lib,mt76x02_usb,mt76x0_common,mt76x0u
mac80211              823296  5 mt76,mt76_usb,mt76x02_lib,mt76x0_common,mt76x0u
cfg80211              679936  3 mt76x02_lib,mac80211,mt76x02_usb

Allerdings geht jetzt das Spiel mit dem Aufhängen wieder los. Dmesg meldet wieder seine Kettenbriefe:

...
[  800.177462] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.177711] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.177961] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.178211] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.178461] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.178712] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.181962] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32
[  800.190850] mt76x0u: probe of 1-1.1.3.2:1.0 failed with error -110
[  825.311384] usb 1-1.1.3.2: USB disconnect, device number 18

schollsky schrieb:

Das könntest Du gefahr- und problemlos mit einer Live-DVD von 19.04 testen - alternativ und schneller vom USB-Stick, und gibt's auch für Ubuntu Studio.

Schon probiert?

Grüße schollsky

Ich habe es jetzt mal getestet, allerdings hing sich Disco Dingo dabei auch auf. ☹

kaekimaster schrieb:

kB schrieb:

Jetzt ist es natürlich spannend, ob der Treiber beim Start des Kernel 5.0.2 mit eingestecktem AVM-WLAN-Stick auch vollständig geladen wird.[…]

Also ist alles da, was benötigt wird und es wird auch automatisch aktiviert.

Allerdings geht jetzt das Spiel mit dem Aufhängen wieder los. Dmesg meldet wieder seine Kettenbriefe:

...
[  800.177462] mt76x0u 1-1.1.3.2:1.0: rx urb failed: -32

Alle Kunst, den rechten Treiber zu verwenden, hilft aber nichts, wenn dieser Treiber offenbar mit der Hardware nicht klarkommt. Du kannst jetzt noch folgendes aus der Kiste der verzweifelten Maßnahmen ausprobieren:

1. Möglicherweise handelt es sich um eine Regression, d.h. der Treiber funktioniert im Kernel 4.19 besser als bei Version 5.0.

2. Möglicherweise gibt es noch Parameter für das Modul mt76x0u oder für von diesem benötigte zusätzliche Module, deren Einstellungen ein besseres Verhalten ergeben. Versuche geeignete Kandidaten zu finden, in etwa mit:

   for M in mt76x0u mt76x02-lib mt76-usb mt76 mac80211 mt76x0-common mt76x02-usb; do echo $M; modinfo -F parm $M ; done 

   (Nicht getestet.)

3. Vertraue auf: Mit einem der nächsten Kernel wird alles besser! Um das zu fördern, solltest Du an geeigneter Stelle einen Bug-Report einwerfen.

kB schrieb:

1. Vertraue auf: Mit einem der nächsten Kernel wird alles besser! Um das zu fördern, solltest Du an geeigneter Stelle einen Bug-Report einwerfen.

Ubuntu Launchpad: Kernel Projekt oder gibts was besseres? So als Backport für DD wäre das nen wichtiger Fix.

kB schrieb:

1. Möglicherweise gibt es noch Parameter für das Modul mt76x0u oder für von diesem benötigte zusätzliche Module, deren Einstellungen ein besseres Verhalten ergeben. Versuche geeignete Kandidaten zu finden, in etwa mit:

   for M in mt76x0u mt76x02-lib mt76-usb mt76 mac80211 mt76x0-common mt76x02-usb; do echo $M; modinfo -F parm $M ; done 

   (Nicht getestet.)

Hier ist die Ausgabe:

kaekimaster@kaeki4:~$ for M in mt76x0u mt76x02-lib mt76-usb mt76 mac80211 mt76x0-common mt76x02-usb; do echo $M; modinfo -F parm $M ; done
mt76x0u
mt76x02-lib
mt76-usb
mt76
mac80211
minstrel_vht_only:Use only VHT rates when VHT is supported by sta. (bool)
max_nullfunc_tries:Maximum nullfunc tx tries before disconnecting (reason 4). (int)
max_probe_tries:Maximum probe tries before disconnecting (reason 4). (int)
beacon_loss_count:Number of beacon intervals before we decide beacon was lost. (int)
probe_wait_ms:Maximum time(ms) to wait for probe response before disconnecting (reason 4). (int)
ieee80211_default_rc_algo:Default rate control algorithm for mac80211 to use (charp)
mt76x0-common
mt76x02-usb

Nur das vom Modul mt76x0u benötigte Modul mac80211 kennt eine Reihe von Optionen, an denen man spielen könnte. Leider habe ich keine Ahnung, was diese Optionen bewirken und ob sie irgendwie dieses "rx urb" aus den Fehlermeldungen beeinflussen könnten. Vielleicht könnte man durch Studium der Quelltexte etwas herausfinden, aber wenn Du diesen steinigen Pfad in einer wasserlosen Wüste gehen willst, dann trennen sich leider hier unsere Wege.

Hallo,
Moduloptionen helfen hier nicht.

Nur bei Reason 4 Fehlern im Syslog (von wpa_supplicant) können in diesem Falls Parameter verändert werden (siehe auch WLAN - Logbucheinträge auswerten):

• max_nullfunc_tries:Maximum nullfunc tx tries before disconnecting (reason 4). (int) - konfigurierbare Anzahl fehlerhafter Tx-Pakete bevor die Verbindung abgebrochen wird (keine/fehlerhafte Antwort von AP)

• max_probe_tries:Maximum probe tries before disconnecting (reason 4). (int) - Anzahl der Versuche/Wiederholungen bei fehlerhaften Tx-Paketen beim ersten Verbindungsaufbau bevor die Verbindung abgebrochen wird

• probe_wait_ms:Maximum time(ms) to wait for probe response before disconnecting (reason 4). (int) - konfigurierbare Pause/Wartezeit auf Antwort des AP bevor die Verbindung abgebrochen wird

Bei Fehlern mit verlorenen Beacons des Accesspoint:

• beacon_loss_count:Number of beacon intervals before we decide beacon was lost. (int) - die Anzahl der Versuche & Pause kann verändert werden/bei Fehlern mit dem AP eine Verbindung auszuhandeln (bei Problemen mit dem 100ms Zeitintervall)

• ieee80211_default_rc_algo: - der Verbindungsalgorithmus bei Verbindungsproblemen kann geändert werden/extrem selten (mögliche Optionen: pid und minstrel)

Übertragungsmodus beeinflussen:

• minstrel_vht_only:Use only VHT rates when VHT is supported by sta. (bool) - Optionen zum n-Übertraugngsmodus (nutze nur n-Modi, sofern angeboten/unterstützt/nur bei sehr guten Verbindungsverhältnissen zu empfehlen)

Beispiel einer Konfigurationsdatei:

1

echo -e "options mac80211 ieee80211_default_rc_algo=pid max_nullfunc_tries=30 max_probe_tries=30 probe_wait_ms=2000" | sudo tee /etc/modprobe.d/mac80211_options.conf

(hier nicht anzuwenden!)

Beacons sind kurze Datenpakete (Leuchtfeuer) des AP mit denen dieser den Clients u.a. mögliche Verbindungsoptionen/Übertragungsvarianten mitteilt

"rx urb" - Fehler sind IMHO Probleme/Überlauf des Empfangspuffers des Geräts/Treibers. Da muss ein Programmierer ran und den Quellcode patchen. → auf Launchpad melden, falls noch nicht geschehen

elektronenblitz63 schrieb:

"rx urb" - Fehler sind IMHO Probleme/Überlauf des Empfangspuffers des Geräts/Treibers. Da muss ein Programmierer ran und den Quellcode patchen. → auf Launchpad melden, falls noch nicht geschehen

Dann werde ich einen Bug Report auf Launchpad einsetzen. Trotz dass das Problem noch besteht, wollte ich mich nochmal bei euch für die tatkräftige Unterstützung danken! Nicht nur dass ich jetzt der Lösung einen Schritt näher bin, sondern ich durfte auch neue Befehle und Infos kennen lernen. 😀

Ich setze das Thema hiermit auf erledigt. Danke euch allen!

Vergiss nicht einen Link hier zu hinterlassen damit andere Leute mit dem Problem die Wichtigkeit betonen können.

frostgram schrieb:

Vergiss nicht einen Link hier zu hinterlassen damit andere Leute mit dem Problem die Wichtigkeit betonen können.

Sobald ich eine Lösung vom Launchpad bekomme, werde ich es hier posten. 😉

kaekimaster schrieb:

frostgram schrieb:

Vergiss nicht einen Link hier zu hinterlassen damit andere Leute mit dem Problem die Wichtigkeit betonen können.

Sobald ich eine Lösung vom Launchpad bekomme, werde ich es hier posten.

Setze doch bitte heute schon hier bei UbuntuUsers.de einen Link auf Deinen Bug-Report auf Launchpad!

Wie frostgram schon schrieb: Betroffene Leser von UbuntuUsers.de können dann den Bug-Report finden und sich auf Launchpad als ebenfalls Betroffene melden und somit die Wichtigkeit des Bug durch Erhöhung des Heat-Wertes betonen.

Hab mir Mühe gegeben, konnte aber auf Launchpad nix passendes finden. kaekimaster , wo genau hast du den Report versteckt? 😉

Hallo zusammen,

bin jetzt leider erst dazu gekommen euch hier den Link zu dem Problem zu posten:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824650

Ich bin derweil wieder auf Powerline umgestiegen, aber ich hoffe trotzdem dass das Problem bald erledigt ist. 😉

kaekimaster kannst du mal den neuen RC Mainline Kernel testen? Hatte das Gefühl dass sich die Sache mit RC5 erledigt hat.

frostgram schrieb:

kaekimaster kannst du mal den neuen RC Mainline Kernel testen? Hatte das Gefühl dass sich die Sache mit RC5 erledigt hat.

Grüß dich frostgram!

Also ich habe es jetzt auch RC5 probiert, aber der Fehler existiert immer noch. Der Treiber wird nicht geladen und Ubuntu friert nach einigen Momenten ein. Die Leute von Launchpad tippen auf ein Upstream Problem was sich seit 4.19 bis zu den aktuellen Kernel durchzieht die released werden.

Ich würde ja auf einen Fehler meinerseits tippen, aber der Fehler tritt bereits bei einer Vanilla Ubuntu Installation auf, ebenso bei den Live CD's/USB-Stick Systemen.