Problem mit TP-Link AC1900 Archer T9E

[rendegast]

... mit original Nvidia-Treiber hatte ich gemeint, dass ich mir den 352er Treiber von Nvidia heruntergeladen und mit dessen Installer installiert hatte.

Detected Nvidia GPUs:
07:00.0 VGA compatible controller [0300] Nvidia Corporation Device [10de:1401] rev a1)
Checking card: Nvidia Corporation Device 1401 (rev a1)

debian bietet an

Code: Alles auswählen

# aptitude versions nvidia-driver$ nvidia-legacy-340xx-driver$ nvidia-legacy-304xx-driver$ --disable-columns
Package nvidia-driver:                         
p  340.96-1 stable 500
p  367.44-3~bpo8+1 jessie-backports 111
p  367.57-1 testing,unstable 101
p  370.28-1 experimental 1


Package nvidia-legacy-304xx-driver:
p  304.131-1 stable 500
p  304.131-8~bpo8+2 jessie-backports 111
p  304.132-1 testing,unstable 101


Package nvidia-legacy-340xx-driver:
p  340.96-9~bpo8+2 jessie-backports 111
p  340.98-1 testing,unstable 101

Mit den 340 ist hier nichts anzufangen, es bleibt 367 jessie-backports:

Code: Alles auswählen

aptitude install -t jessie-backports  nvidia-settings/jessie-backports nvidia-driver nvidia-kernel-dkms nvidia-alternative

aptitude install

Dann mit einem

Code: Alles auswählen

dpkg -l   |  grep nvidia

kontrollieren, Überbleibsel anderen nvidia-Pakete entfernen.
Wurden Module für alle Kernel gebaut?:

Code: Alles auswählen

dkms status

Eine Vorbedingung: Die headers der entsprechenden Kenrel sind installiert.

Deinen Vorschlag mit dem nvidia-installer-cleanup wollte ich gerade umsetzen, erhalte aber widerspruechliche Aussagen:

Da ist nicht widersprüchliches. Das Paket enthält kein binary zur händischen Ausführung, es wird automatisch ausgeführt.

# dpkg-query -L nvidia-installer-cleanup | sort
/.
/usr
/usr/lib
/usr/lib/nvidia
/usr/lib/nvidia/alternate-install-present
/usr/lib/nvidia/check-for-conflicting-opengl-libraries
/usr/lib/nvidia/pre-install
/usr/share
/usr/share/doc
/usr/share/doc/nvidia-installer-cleanup
/usr/share/doc/nvidia-installer-cleanup/changelog.gz
/usr/share/doc/nvidia-installer-cleanup/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/nvidia-installer-cleanup

Gegebenenfalls ein 'dpkg-reconfigure nvidia-installer-cleanup',
dazu braucht es wiederum
/usr/bin/nvidia-installer
/usr/bin/nvidia-uninstall
sprich eine aktive Installation eines nvidia-Installers.





----------------------------------------------
Anmerkung
oben schon gesagt, nvidia-Installer arbeitet seit längerem schon mit dkms
(obwohl, die entsprechende Abfrage zur dkms-Registrierung wird beim einfachen Durchklicken mit 'no' beantwortet).
Bei der Installation des kernel 4.7 jessie-backports wurde die dkms-Installation des 352-Moduls bestimmt angestoßen
(da er vermutlich auch der neueste der installierten Kernel ist).
Wenn das 352-Modul nicht gebaut werden konnte, so gab es bestimmt eine Meldung.

Wurde keine dkms-Registrierung des 352 gemacht,
so ist das das www-weite Standardproblem des Installers: "neuer Kernel, habe kein Bild mehr"
www-weite Standardlösung: "Führe den Installer nochmal aus"

[vdvogt]

Hallo rendegast,
ich habe Deine Empfehlung umgesetzt:

Code: Alles auswählen

aptitude install -t jessie-backports  nvidia-settings/jessie-backports nvidia-driver nvidia-kernel-dkms nvidia-alternative

aptitude install

Dann mit einem

Code: Alles auswählen

dpkg -l   |  grep nvidia

kontrollieren, Überbleibsel anderen nvidia-Pakete entfernen.

Die Ausgabe ergab viel 367er Pakete, die sind wohl alle Ok.
Aber auch diese hier:
nvidia-modprobe 358.09-1~bpo+1
nvidia-persistenced 358.09-1~bpo+1
nvidia-settings 340.93-1~bpo8+1

Was muss ich da genau eingeben, damit ich gezielt dies Pakete purgen kann?
Was das settings-Paket anbetrifft, so ist wohl das aus den Jessie-backports nicht installiert worden.
Wenn das 340er weg ist, soll ich das dann nochmal versuchen, das aus den jessie-backports zu installieren?

Wurden Module für alle Kernel gebaut?:

Code: Alles auswählen

dkms status

Eine Vorbedingung: Die headers der entsprechenden Kenrel sind installiert.

Ja, die headers hatte ich fuer den 4.7er Kernel installiert.

Die Ausgabe ergab drei Zeilen:
Bei den ersten beiden war alles Ok.
Die Dritte:
vboxhost, 5.0.0, 3.16.0-4-amd64, x86_64, installed (Warning! Diff between built and installed module!)
Wie kann ich das bereinigen?

Wenn das alles geschafft ist, steht hoffentlich nach einem Reboot wieder eine GUI zur Verfuegung???

Viele Gruesse
Veit

[rendegast]

Code: Alles auswählen

$ aptitude versions nvidia-modprobe nvidia-persistenced nvidia-settings --disable-columns
Paket nvidia-modprobe:                                                         
p A 340.46-1 stable 500
i A 358.09-1~bpo8+1 jessie-backports 111
p A 367.44-1 testing,unstable 101

Paket nvidia-persistenced:
p  358.09-1~bpo8+1 jessie-backports 111
p  367.57-1 testing,unstable 101


Paket nvidia-settings:
p  340.46-2 stable 500
p  340.93-1~bpo8+1 jessie-backports 111
p  340.93-1 testing 101
p  343.36-2 unstable 100
p  346.59-1 experimental 1

Paket nvidia-settings-legacy-304xx:
p  304.123-2 stable 500
p  304.128-1~bpo8+1 jessie-backports 111
p  304.128-1 testing 101
p  304.132-1 unstable 100

Paket nvidia-settings-legacy-340xx:
p  340.93-1~bpo8+1 jessie-backports 111
p  340.93-1 testing 101
p  340.98-1 unstable 100

Die Funktion dieser Pakete ist wohl eher allgemeiner Natur, siehe deren Beschreibung,
deren eigentliche Version also nicht so wichtig.
(Leider verwirrend)

Die Dritte:
vboxhost, 5.0.0, 3.16.0-4-amd64, x86_64, installed (Warning! Diff between built and installed module!)

Der dkms-Mechanismus der virtualbox-Pakete von oracle ist etwas buggy und ihm muß gelegentlich durch händischen Eingriff per 'dkms' nachgeholfen werden.
Auch finden sich gelegentlich vbox-Module nicht durch den dkms-Mechanismus in /lib/modules/KERNELVERSION/,
welche Konflikte hervorrufen und händisch entfernt werden müssen.

Code: Alles auswählen

find /lib/modules  |  sort -V  |  grep vbox

Gegebenenfalls nötiges händische Entfernen:
- Entsprechendes Modul löschen
- 'depmod -a' für den Kernel ausführen
Gegebenenfalls nötiger virtualbox-dkms-"Reset":
- 'dkms remove -m virtualbox ....'
- 'dkms install -m virtualbox ...' für die entsprechenden kernel

"Walkaround": virtualbox aus dem debian-Repo:

Code: Alles auswählen

$ aptitude versions virtualbox:amd64 --disable-columns
Paket virtualbox:                                                         
p  4.3.36-dfsg-1+deb8u1 stable 500
i  5.1.8-dfsg-6~bpo8+2 jessie-backports 111
p  5.1.8-dfsg-6 testing,unstable 101

Einschränkung: debians virtualbox verhält sich in einigen eventuell nicht doch so unwichtigen Kleinigkeiten anders.

[vdvogt]

Hallo rendegast,
nach einem beherzten Reboot habe ich jetzt wieder eine GUI!!!!!!

Vielen, vielen Dank fuer Deine Hilfe!

Allerdings gibt es jetzt noch ein kleines Problem:
Da ich einige Projekte bei BOINC rechnen lasse, wurde jetzt nach dem Neustart keine GPU gefunden.
Ich benoetige noch Pakete fuer cuda und opengl.

Kannst Du mir die bitte noch nennen, welche ich da brauche.

Das Problem mit der vbox habe ich durch purgen der vbox geloest, da ich die auf dem Rechner nicht mehr brauche.

Ausserdem funktioniert jetzt gar kein WLAN mehr.
Da muessen wir nochmal dran arbeiten.

Viele Gruesse
Veit

[rendegast]

boinc-client-nvidia-cuda?
nvidia-cuda-toolkit?
nvidia-cuda-mps?
boinc-nvidia-cuda?

Nur so eine erste Sichtung in aptitude.

Ausserdem funktioniert jetzt gar kein WLAN mehr.
Da muessen wir nochmal dran arbeiten.

Fehlt einfach nur ein firmware-Paket?

Code: Alles auswählen

dmesg  |  egrep -i "fw|firm"

lspci -nn
lsusb
lsmod

[vdvogt]

Hallo rendegast,

dmesg | egrep -i "fw|firm"

[ 2.668381] firewire_core 0000:0a:00.0: created device fw0: GUID 0010dc0001d40947, S400
[ 6.963026] HW 0001000d FW 00010004
[ 10.773649] r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

lspci -nn
lsusb
lsmod

lspci -nn
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
05:00.0 Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)

lsusb
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 011 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 008 Device 004: ID 1a86:7584 QinHeng Electronics CH340S
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsmod
Module Size Used by
nf_conntrack_ipv4 20480 18
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
xt_tcpudp 16384 18
xt_conntrack 16384 18
nf_conntrack 114688 2 xt_conntrack,nf_conntrack_ipv4
cfg80211 577536 0
ip6table_filter 16384 0
rfkill 24576 1 cfg80211
ip6_tables 24576 1 ip6table_filter
iptable_filter 16384 1
ip_tables 24576 1 iptable_filter
x_tables 36864 6 ip6table_filter,ip_tables,xt_tcpudp,xt_conntrack,iptable_filter,ip6_tables
nfsd 323584 2
auth_rpcgss 61440 1 nfsd
nfs_acl 16384 1 nfsd
nfs 253952 0
lockd 90112 2 nfs,nfsd
grace 16384 2 nfsd,lockd
fscache 61440 1 nfs
sunrpc 335872 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
kvm_amd 69632 0
snd_hda_codec_hdmi 49152 1
kvm 581632 1 kvm_amd
irqbypass 16384 1 kvm
crct10dif_pclmul 16384 0
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
stv6110x 16384 4
lnbp21 16384 4
hmac 16384 1
drbg 24576 1
usblp 20480 0
joydev 20480 0
ansi_cprng 16384 0
aesni_intel 167936 0
snd_hda_codec_realtek 86016 1
aes_x86_64 20480 1 aesni_intel
lrw 16384 1 aesni_intel
gf128mul 16384 1 lrw
snd_hda_codec_generic 73728 1 snd_hda_codec_realtek
glue_helper 16384 1 aesni_intel
ablk_helper 16384 1 aesni_intel
cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_hda_intel 36864 4
mxm_wmi 16384 0
evdev 24576 20
snd_hda_codec 131072 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
stv090x 73728 4
pcspkr 16384 0
ddbridge 24576 30
serio_raw 16384 0
snd_hda_core 81920 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep 16384 1 snd_hda_codec
dvb_core 118784 1 ddbridge
fam15h_power 16384 0
k10temp 16384 0
snd_pcm 110592 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
snd_timer 32768 1 snd_pcm
tpm_infineon 20480 0
acpi_cpufreq 20480 0
snd 81920 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
tpm_tis 20480 0
soundcore 16384 1 snd
wmi 16384 1 mxm_wmi
sp5100_tco 16384 0
shpchp 36864 0
i2c_piix4 24576 0
tpm 45056 2 tpm_tis,tpm_infineon
button 16384 0
nvidia_drm 45056 1
drm_kms_helper 147456 1 nvidia_drm
drm 360448 4 drm_kms_helper,nvidia_drm
nvidia_modeset 765952 4 nvidia_drm
nvidia 11472896 58 nvidia_modeset
f71882fg 36864 0
fuse 98304 1
parport_pc 28672 0
ppdev 20480 0
lp 20480 0
parport 49152 3 lp,ppdev,parport_pc
autofs4 40960 2
ext4 602112 2
crc16 16384 1 ext4
jbd2 110592 1 ext4
mbcache 16384 3 ext4
raid456 106496 2
async_raid6_recov 20480 1 raid456
async_memcpy 16384 2 raid456,async_raid6_recov
async_pq 16384 2 raid456,async_raid6_recov
async_xor 16384 3 async_pq,raid456,async_raid6_recov
async_tx 16384 5 async_pq,raid456,async_xor,async_memcpy,async_raid6_recov
xor 24576 1 async_xor
raid6_pq 102400 3 async_pq,raid456,async_raid6_recov
libcrc32c 16384 1 raid456
crc32c_generic 16384 0
md_mod 131072 3 raid456
hid_logitech_hidpp 28672 0
hid_logitech_dj 20480 0
usbhid 49152 0
hid 118784 5 usbhid,hid_logitech_dj,hid_logitech_hidpp
sr_mod 24576 0
cdrom 57344 1 sr_mod
sg 32768 0
sd_mod 49152 24
ohci_pci 16384 0
crc32c_intel 24576 1
psmouse 122880 0
ahci 36864 18
ohci_hcd 49152 1 ohci_pci
xhci_pci 16384 0
firewire_ohci 40960 0
libahci 32768 1 ahci
ehci_pci 16384 0
firewire_core 65536 1 firewire_ohci
libata 245760 2 ahci,libahci
xhci_hcd 176128 1 xhci_pci
crc_itu_t 16384 1 firewire_core
ehci_hcd 77824 1 ehci_pci
usbcore 241664 8 usblp,ohci_hcd,ohci_pci,ehci_hcd,ehci_pci,usbhid,xhci_hcd,xhci_pci
scsi_mod 225280 4 sg,libata,sd_mod,sr_mod
r8169 81920 0
usb_common 16384 1 usbcore
mii 16384 1 r8169
fjes 28672 0


Ich hoffe, Du kannst mit den Ausgaben was anfangen.

Viele Gruesse
Veit

[rendegast]

05:00.0 Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)

Sollte vom Kernel bedient werden mit Modul bcma,
dann wohl > Modul broadcom > bcm-phy-lib > ...
'ip link'.
Eventuell/Wohl noch firmware-Paket zBsp. (ohne spezielle Erfahrung nach "broadcom" gesucht)
b43-fwcutter
firmware-b43-installer
firmware-b43legacy-installer
firmware-brcm80211
(firmware-misc-nonfree über firmware-linux-nonfree)
?

Warum zum Teufel wird Modul bcma nicht bei Deinem 'lsmod' aufgeführt?
Suche nach "bcma" in 'dmesg' (mit ein bischen Zeilenkontext).


Alternativ Modul wl aus broadcom-sta-dkms:
'$ cat broadcom-sta-dkms_6.30.223.271-4_all/usr/share/broadcom-sta/broadcom-sta.ids':

# commented out devices are supported by a free driver according to
# http://wireless.kernel.org/en/users/Dri ... ed_devices
# 14e44311 supported by b43
# 14e44312 supported by b43
14e44313
# 14e44315 supported by b43
14e44727
# 14e44328 At least on a MacBook Air (MacBookAir2,1) this device is not supported by broadcom-sta
# 14e44329 supported by b43/brcmfmac
14e4432a
14e4432b
# 14e4432c supported by b43
14e4432d
# 14e44331 supported by b43
# 14e44353 supported by b43/brcm80211
# 14e44357 supported by b43/brcm80211
14e44358
14e44359
14e44365
14e443a0
14e443b1

[vdvogt]

Hallo rendegast,
wenn ich Deine Hinweise richtig deute, dann muss ich das Paket broadcom-sta-dkms noch mal installieren.
Aber wieder aus den jessie-backports.

Gruesse
Veit

[rendegast]

Du könntest auch mal nachforschen, warum Modul bcma für den broadcom nicht geladen wurde.
Siehe meinen editierten Beitrag oben.

Warum zum Teufel wird Modul bcma nicht bei Deinem 'lsmod' aufgeführt?
Suche nach "bcma" in 'dmesg' (mit ein bischen Zeilenkontext).

... dann muss ich das Paket broadcom-sta-dkms noch mal installieren.
Aber wieder aus den jessie-backports.

Es wäre aber wohl keine Änderung gegenüber dem Standardkernel 3.16 mit dem Modul wl jessie-backports zu erwarten.
EDIT: oben schonmal geschrieben, nur broadcom-sta-dkms stretch/testing baut auch mit kernel 4.7 jessie-backports.

[vdvogt]

Hallo rendegast,
ich habe mit dmesg | grep bcma gesucht, aber keine Ausgabe erhalten.
Auch nichts, wenn ich nur nach bcm, oder nur bc suche.
Kann es sein, dass das bei mir gar nicht installiert ist?

Laut dieser seite:
https://wiki.debian.org/wl
steht bcma in Konflikt mit broadcom-sta-dkms.
Wenn ich das richtig sehe, dann sollte ich das nicht installieren.
Wie siehst Du das?

modprobe wl
modprobe: FATAL: Module wl not found.

Gruesse
Veit

[vdvogt]

Hallo rendegast,
ich habe gerade deine Aenderung eines vorigen Posts gesehen.

EDIT: oben schonmal geschrieben, nur broadcom-sta-dkms stretch/testing baut auch mit kernel 4.7 jessie-backports.

Wie muss ich das verstehn?
Heisst das, dass das Paket broadcom-sta-dkms nur aus strech bzw. testing nicht aber das aus jessie-backports mit dem 4.7er Kernel gebaut werden kann?

Gruesse
Veit

[rendegast]

ich habe mit dmesg | grep bcma gesucht, aber keine Ausgabe erhalten.
Auch nichts, wenn ich nur nach bcm, oder nur bc suche.
Kann es sein, dass das bei mir gar nicht installiert ist?

bcma = Modul vom Kernelpaket mitgebracht
wl = Unfreies 3rd-party-Modul aus Paket broadcom-sta-dkms, bei Installation werden die broadcom-Module des Kernelpaketes per blacklist deaktiviert.

... dann muss ich das Paket broadcom-sta-dkms noch mal installieren.
Aber wieder aus den jessie-backports.

schonmal geschrieben: Nur broadcom-sta-dkms stretch/testing baut auch mit kernel 4.7 jessie-backports.

Hast Du broadcom-sta-dkms oder Reste davon noch auf dem System?

Code: Alles auswählen

dpkg -l  |  egrep -i "broadcom|b43"
dkms status

Ein installiertes broadcom-sta-dkms nicht_stretch oder nur entferntes aber nicht gepurgtes broadcom-sta-dkms wäre eine Erklärung dafür, daß weder wl noch bcma in Deinem 'lsmod' auftaucht.
Auch für

modprobe wl
modprobe: FATAL: Module wl not found.

EDIT --------------------------------------------------

Heisst das, dass das Paket broadcom-sta-dkms nur aus strech bzw. testing nicht aber das aus jessie-backports mit dem 4.7er Kernel gebaut werden kann?

Genau das.
Anmerkung, das Paket aus stretch ist ansonsten problemlos.

[vdvogt]

Hallo rendegast,

dpkg -l | egrep -i "broadcom|b43"
ii b43-fwcutter 1:019-2 amd64 utility for extracting Broadcom 43xx firmware
ii broadcom-sta-dkms 6.30.223.271-2~bpo8+1 all dkms source for the Broadcom STA Wireless driver
ii firmware-b43-installer 1:019-2 all firmware installer for the b43 driver

Die b43-Pakete hatte ich bei meinem allerersten Versuch zum WLAN-Adapter installiert, ich dache, die sind laengst weg.
Aber anscheinend habe ich die nicht richtig geloescht.
Die stehen im Konflikt mit broadcom-sta-dkms, muessen also ganz weg!

dkms status
broadcom-sta, 6.30.223.271, 3.16.0-4-amd64, x86_64: installed
nvidia-current, 367.44, 4.7.0-0.bpo.1-amd64, x86_64: installed

Wie kann ich broadcom-sta-dkms aus stretch installieren, ohne es in den sources.list drin zu haben?
Wahrscxheinlich nicht.
D.h. ich muss stretch nur fuer dieses eine mal in die sources.list aufnehem und dann sofort wieder ruasloeschen.
Aber erst mal muss ich das alte Paket loswerden. Wie?

Gruesse
Veit

[rendegast]

Die b43-Pakete ...
Die stehen im Konflikt mit broadcom-sta-dkms, muessen also ganz weg!

Nein, nein.
broadcom-sta-dkms deaktiviert die mitgebrachten Module des Kernels
(diese würden auf die firmware der diversen broadcom-firmware-Pakete zurückgreifen)
Es gibt keinen Konflikt.

ii broadcom-sta-dkms 6.30.223.271-2~bpo8+1 all
damit wird kein Modul für kernel 4.7 gebaut, dennoch gilt die blacklist des Paketes.
Du könntest/solltest broadcom-sta-dkms mal per 'purge' entfernen, um das Modul des Kernels bcma auszuprobieren.
Das war ja auch der Sinn der Installation des kernel 4.7 jessie-backports.

Von den firmware-Paketen gibt es diverse (oben schonmal gelistet),
nach Kernelmeldungen 'dmesg' des Moduls bcma kann mehr gesagt werden.
Heißester Kandidat hier imo firmware-brcm80211 (jessie-backports)
(benutzt von den Modulen brcmfmac und brcmsmac.
Werden vermutlich über Modulmechanismen passend hinzugeladen,
ähnlich den codec des snd_hda_intel.).

Wie kann ich broadcom-sta-dkms aus stretch installieren, ohne es in den sources.list drin zu haben?

broadcom-sta-dkms
Diesem Link für stretch folgen gibt die Möglichkeit zum Download.
Installation per 'dpkg'.

Aber erst mal muss ich das alte Paket loswerden. Wie?

Würde bei der Installation ersetzt.

[vdvogt]

Hallo rendegast,
ich habe jetzt das alte broadcom-sta-dkms gepurged und danach aus den stretch quellen das neue Paket installiert.
Aber leider immer noch keine WLAN-Verbindung.
nach einem modprobe wl habe ich jetzt wieder Verbindung zum 2.4GHz-Netz, aber immer noch nichts zum 5GHZ-Netz.

Muss ich da erst nochmal ein Reboot machen?


Ausserdem nach eine Frage zur Installation:
Es kommen immer diese Meldungen zu rtl....
DKMS: install completed.
Trigger für initramfs-tools (0.120+deb8u2) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.7.0-0.bpo.1-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for module r8169

Wenn ich das richtig interpretiere, handelt es sich um Pakete fuer den eth0?
Wie ich gerede noch recherchiert habe, muss ich auch hier das Paket aus jessie-backports installieren.
OK. Habe ich gerade gemacht.

Gruesse
Veit

[rendegast]

das alte broadcom-sta-dkms gepurged und danach aus den stretch quellen das neue Paket installiert.
Aber leider immer noch keine WLAN-Verbindung.
nach einem modprobe wl habe ich jetzt wieder Verbindung zum 2.4GHz-Netz, aber immer noch nichts zum 5GHZ-Netz.

Und wie läuft es mit dem kerneleigenen Treiber bcma / brcm*?

Code: Alles auswählen

systemctl stop networking.service
service networking stop

modprobe -vr wl
aptitude purge broadcom-sta-dkms
aptitude install firmware-brcm80211/jessie-backports
update-initramfs -u -kall

# /etc/udev/rules.d/*persistent-net* falls vorhanden verschieben
modprobe -v bcma
oder vielleicht besser
<Neustart>

Code: Alles auswählen

ip link
dmesg  |  egrep -i "bcm|brcm|broadcom|wl|80211|firmware" -C1
lsmod   |  egrep -i "bcm|brcm|broadcom|wl|80211" -C1

Eventuell muß brcmutil / brcmsmac doch händisch geladen werden,
kenne mich mit broadcom nicht aus.
Aber erstmal den Neustart abwarten.

[vdvogt]

Hallo rendegast,

Code: Alles auswählen

systemctl stop networking.service
service networking stop

modprobe -vr wl
aptitude purge broadcom-sta-dkms
aptitude install firmware-brcm80211/jessie-backports
update-initramfs -u -kall

Alles erfolgreich ausgefuehrt.

Code: Alles auswählen

/etc/udev/rules.d/*persistent-net* falls vorhanden verschieben
modprobe -v bcma

*persistent-net* nach OLD_*persistent-net* verschoben
modprobe ausgefuehrt

Code: Alles auswählen

ip link
dmesg  |  egrep -i "bcm|brcm|broadcom|wl|80211|firmware" -C1
lsmod   |  egrep -i "bcm|brcm|broadcom|wl|80211" -C1

Ausgaben:

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 44:8a:5b:83:bd:ba brd ff:ff:ff:ff:ff:ff


dmesg | egrep -i "bcm|brcm|broadcom|wl|80211|firmware" -C1
[ 6.706864] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20
[ 6.769428] bcma: bus0: Found chip with id 0x4360, rev 0x03 and package 0x01
[ 6.769449] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, class 0x0)
[ 6.769461] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, class 0x0)
[ 6.769481] bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 0x0)
[ 6.769502] bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, class 0x0)
[ 6.769513] bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, class 0x0)
[ 6.801767] bcma: Unsupported SPROM revision: 11
[ 6.801810] bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
[ 6.801811] bcma: bus0: Using fallback SPROM failed (err -2)
[ 6.801812] bcma: bus0: No SPROM available
[ 6.803899] bcma: bus0: Bus registered
[ 6.824768] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
--
[ 7.423540] DDBridge 0000:06:00.0: DVB: registering adapter 3 frontend 0 (STV090x Multistandard)...
[ 7.444229] b43-phy0: Broadcom 4360 WLAN found (core revision 42)
[ 7.444563] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)
[ 7.444610] b43: probe of bcma0:1 failed with error -95
[ 7.444628] Broadcom 43xx driver loaded [ Features: PNLS ]
[ 7.775822] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:0b.0/0000:07:00.1/sound/card1/input15
--
[ 10.512173] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 10.967210] r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw
[ 11.069402] r8169 0000:02:00.0 eth0: link down


lsmod | egrep -i "bcm|brcm|broadcom|wl|80211" -C1
kvm 581632 1 kvm_amd
mac80211 647168 1 b43
irqbypass 16384 1 kvm
cfg80211 577536 2 b43,mac80211
crct10dif_pclmul 16384 0
--
hmac 16384 1
rfkill 24576 1 cfg80211
snd_hda_codec 131072 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
--
sp5100_tco 16384 0
bcma 53248 1 b43
tpm_infineon 20480 0

Ergebnis:
LAN-Verbindung vorhanden.
Absolut kein WLAN!

Ich denke, das mit broadcom-sta-dkms war besser, wenistens hatte ich da eine WLAN-Verbindung mit dem 2,4GHz-Netz.

Wie siehst Du das?

Viele Gruesse
Veit

[rendegast]

Die Ausgabe ist doch schonmal was.

[ 7.444229] b43-phy0: Broadcom 4360 WLAN found (core revision 42)

Damit kann ich aber nichts anfangen, fehlende Erfahrung:

[ 7.444563] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)
[ 7.444610] b43: probe of bcma0:1 failed with error -95
[ 7.444628] Broadcom 43xx driver loaded [ Features: PNLS ]

Leider keine Meldung bzgl. firmware(?), das wäre wenigstens eine einfache Schraube zum dran drehen.
Wobei ich die broadcom(-Treiber) ansich etwas "speziell" finde.


Nach ein bischen Herumsuchen im kernel-Quelltext "broadcom" und Kontrolle meiner /boot/config*
/boot/config-3.16.0-4-amd64
/boot/config-4.6.0-0.bpo.1-amd64
/boot/config-4.7.0-0.bpo.1-amd64
/boot/config-4.8-custom
-> Keines hat den Wert B43_PHY_AC ("Say N, this is BROKEN and crashes driver").
Also wird ac mit den Kerneltreibern wohl generell nicht möglich sein.
n im 5GHz-Netz? Kann da den Quelltext nicht deuten.



Viel Glück mit wl/broadcom-sta-dkms 6.30.223.271 stretch,
zumindest n/2GHz scheint ja zu funktionieren.

[vdvogt]

Hallo rendegast,
also alles wieder zurueck!

systemctl stop networking.service
modprobe -vr wl
aptitude purge firmware-brcm80211/jessie-backports
dpkg -i broadcom-sta-dkms_6.30.223.271-4_all.deb
update-initramfs -u -kall

Ist das so richtig?

Gruesse
Veit

[rendegast]

Ist das so richtig?

Im Endeffekt schon.
Noch die Kontrolle auf Module aller Kernel, 'dkms status'.


Wobei

modprobe -vr wl
aptitude purge firmware-brcm80211/jessie-backports

wl wurde ja schon entladen und Paket entfernt.
Also eher

Code: Alles auswählen

modprobe -vr b43
modprobe -vr bcma
...

Darüberhinaus
"... purge firmware-brcm80211/jessie-backports"
Die Repo-Angabe '/....' ist beim purge/remove sinnlos. (sogar invalid?)

Bei suse können Pakete in mehreren Versionen vorliegen, Paradebeispiel kernel:
linux-generic 1.2.3
linux-generic 1.2.4
...
Wobei dann sowas käme

Code: Alles auswählen

zypper rm linux-generic-1.2.3

[vdvogt]

Hallo rendegast,

vielen Dank fuer Deine Hilfe!

Eine letzte Frage habe ich noch in Bezug auf 802.11ac:

Kennst Du einen PCIe-WLAN-Adapter, der jetzt schon von Linux fuer ac unterstuetzt wird?
Den wuerde ich mir dann kaufen und versuchen, den TP-Link wieder loszuwerden.

Viele Gruesse
Veit

[vdvogt]

HALT!

Doch noch was vergessen:

Ich habe ja /etc/udev/rules.d/70-persistent-net.rules nach OLD_70.... verschoben.

Das muss ich ja auch noch rueckgaengig machen.

Ich habe jetzt zwei files, allerdings mit unterschiedlichen Inhalten:

/etc/udev/rules.d# cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:8a:5b:83:bd:ba", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x43a0 (wl)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a4:2b:b0:e2:d9:4b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"



OLD_70-persistent-net.rules_OLD
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:8a:5b:83:bd:ba", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x168c:0x0030 (ath9k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e827:08:84:34", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x1814:0x0601 (rt2800pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80:1f:02:08:65:78", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"

# PCI device 0x14e4:0x43a0 (wl)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a4:2b:b0:e2:d9:4b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan2"


Welchen von beiden soll ich behalten?
Insbesondere, da mein wlan jetzt wieder wlan0 heisst.
Nachdem mein erster wlan-Adapter kaputtgegangen war, hatte ich voruebergehend einen alten dran (wlan1) bis ich den neuen TP-Link bekommen habe.
Nach dem Einbau des TP_Link hatte sich das veraendert auf wlan2, wie man dem OLD_70...file entnehmen kann.

Gruesse
Veit

[rendegast]

Ich habe ja /etc/udev/rules.d/70-persistent-net.rules nach OLD_70.... verschoben.

Einmal, um es zu verschieben, muß es aus diesem Verzeichnis raus.
In Deinem Fall war das "Umbenennen"

Damit es dort nicht mehr wirkt, darf es als Namen NICHT "irgendwas.rules" haben.
'udevadm test ....'

Wie Du gemerkt hast, wird die Datei neu erstellt.
Du kannst sie also auch jederzeit löschen.

[vdvogt]

Hallo rendegast,
OK, habe ich geloescht.

Ich moechte aber nochmal auf meine Frage vom vorletzten Post zurueckkommen, da ja mein TP-Link mit ac nicht unterstuetzt wird:

Kennst Du einen PCIe-WLAN-Adapter, der jetzt schon von Linux fuer ac unterstuetzt wird?
Den wuerde ich mir dann kaufen und versuchen, den TP-Link wieder loszuwerden.

Viele Gruesse
Veit