Weevil
Anmeldungsdatum: 24. September 2021
Beiträge: Zähle...
|
Hallo zusammen,
ich verzweifle bei einem neu zusammengebastelten PC zunehmend daran, dass es mir nicht gelingt, den Netzwerkadapter dazu zu bringen, ordnungsgemäß seine Arbeit zu tun. Habe im Laufe der letzten Tage schon zig Stunden mit Recherche und herumprobieren verbracht. Kann leider auch nicht von mir behaupten, dass ich wirklich Ahnung von der Materie hätte. Zur Not könnte ich natürlich einen separaten Netzwerkadapter kaufen, aber ich habe jetzt schon so absurd viel Zeit in allerlei Recherche und Problembewältigung beim Aufbau dieses Systems investiert, dass das einfach gefälligst zu funktionieren hat. (z.B. (sorry für Offtopic, muss ein bisschen mein Leid klagen) erstmal ein Mainboard zurückschicken müssen, weil man ja nirgends erfährt mit welcher BIOS Revision die Boards verkauft werden. Und man dann dasteht mit einer CPU, die erst dann unterstützt würde, wenn man mit Hilfe einer anderen CPU ein BIOS Update drauflädt. Und dann ein Sch*** Board kaufen müssen, bei dem ich eigentlich sogar vorher wusste, dass die Linux-Unterstützung schlecht ist, aber welches halt eine Funktion zum BIOS flashen ohne Prozessor besitzt...)
Also, die Situation ist folgende:
verbaut ist auf dem Mainboard soweit ich weiß der Realtek 8118 Chipsatz https://www.realtek.com/en/products/communications-network-ics/item/rtl8118as lshw
*-network UNGEFORDERT
Beschreibung: Ethernet controller
Produkt: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Hersteller: Realtek Semiconductor Co., Ltd.
Physische ID: 0
Bus-Informationen: pci@0000:03:00.0
Version: 16
Breite: 64 bits
Takt: 33MHz
Fähigkeiten: cap_list
Konfiguration: latency=0
Ressourcen: ioport:f000(Größe=256) memory:fcd04000-fcd04fff memory:fcd00000-fcd03fff
sudo dmesg | grep eth
[ 2.688445] r8169 0000:03:00.0 eth0: RTL8168h/8111h, 18:c0:4d:98:99:fb, XID 541, IRQ 45
[ 2.688448] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2.689053] r8169 0000:03:00.0 enp3s0: renamed from eth0
Soweit ich das verstanden habe, wird von so ziemlich allen Linux-Distros für Netzwerkchipsets der Realtek RTL8111/8168/8411 - Familie (zu der auch der RTL8118 irgendwie gehört) standardmäßig der Treiber R8169 verwendet. Außerdem gibt es noch den R8168-Treiber, der wohl die adäquate proprietäre Lösung seitens Realtek darstellt. Probleme mit diesen Chipsets unter Linux sind offenbar nicht ungewöhnlich und man findet unzählige Diskussionen in den einschlägigen Foren, aber die passende Lösung für mich konnte ich nicht finden.
Herumprobiert habe ich bisher mit der Installation von Xubuntu 21.04, daily builds von 21.10 sowie 20.04LTS und mit mehreren Treiberversionen. Sämtliche dependencies erstmals manuell mittels anderem Rechner finden / auf USB-Stick laden / installieren zu müssen ist der Freude am herumprobieren allerdings eher abträglich.
Die Symptome sehen so aus: In einer frischen Xubuntu Installation gibt es (für mich als Laie) keinerlei Fehlermeldungen, nur kommt MEISTENS keine Verbindung zustande. Kurioserweise hat der R8169 Treiber bereits sporadisch funktioniert, allerdings kam die Verbindung erst einige Minuten nach Systemstart zustande (oder u.U. als Reaktion auf eigentlich diagnostische Konsolenbefehle?). Des weiteren gab es nach dem Start eines Live-Systems vom frisch bespielten (!?) USB-Stick schon mehrfach eine funktionierende Netzwerkverbindung. Mit dem "r8168-dkms"-Treiber (https://ubuntu.pkgs.org/20.04/ubuntu-updates-universe-amd64/r8168-dkms_8.048.00-1ubuntu0.20.04.2_all.deb.html) hatte ich ebenfalls kein Glück. Es werden ebenfalls entweder erfolglose Verbindungsversuche angezeigt oder eine Verbindung, die aber nicht funktioniert. Bei diesen Versuchen habe ich auch brav den r8169 auf die blacklist gesetzt.
echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist.conf
Direkt auf der Realtek Homepage findet man außerdem noch eine neuere Version dieses Treibers (Version 8.049.02, https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software). Es ist mir allerdings (glaube ich) nicht gelungen, diesen korrekt/vollständig zu installieren. Ich vermute, das hängt damit zusammen dass der Treiber als GBE Ethernet LINUX driver r8168 for kernel up to 5.6 ausgewiesen ist - während aktuelle Ubuntu-Versionen & Derivate soweit ich das sehe kernel 5.11 oder höher verwenden. Aus den Fehlermeldungen bei Installationsversuchen werde ich nicht recht schlau.
[...]/r8168-8.049.02$ sudo ./autorun.sh
Check old driver and unload it.
Build the module and install
make[2]: gcc: Datei oder Verzeichnis nicht gefunden
arch/x86/Makefile:140: CONFIG_X86_X32 enabled but no binutils support
make[2]: gcc: Datei oder Verzeichnis nicht gefunden
/bin/sh: 1: gcc: not found
make[3]: *** [scripts/Makefile.build:288: /home/boeck/Schreibtisch/r8168-8.049.02/src/r8168_n.o] Fehler 127
make[2]: *** [Makefile:1848: /home/boeck/Schreibtisch/r8168-8.049.02/src] Fehler 2
make[1]: *** [Makefile:150: modules] Fehler 2
make: *** [Makefile:41: modules] Fehler 2
oder auch
Check old driver and unload it.
Build the module and install
Skipping BTF generation for /home/boeck/Schreibtisch/r8168-8.049.02/src/r8168.ko due to unavailability of vmlinux
arch/x86/Makefile:148: CONFIG_X86_X32 enabled but no binutils support
cp: reguläre Datei '/lib/modules/5.13.0-16-generic/kernel/drivers/net/ethernet/realtek/r8168.ko' kann nicht angelegt werden: Keine Berechtigung
make[3]: *** [scripts/Makefile.modinst:81: /lib/modules/5.13.0-16-generic/kernel/drivers/net/ethernet/realtek/r8168.ko] Fehler 1
make[2]: *** [Makefile:1800: modules_install] Fehler 2
make[1]: *** [Makefile:166: install] Fehler 2
Dabei ist auffällig, dass der Vermerk "Check old driver and unload it." auch dann kommt, wenn gar keiner geladen ist (rmmod 8169 / apt-get purge r8169).
An sich möchte ich eher ungern manuell eine fixe Netzwerkkonfiguration durchführen (nicht, dass ich wirklich wüsste, wie...) und auch sonst keine Flickschusterei, die bei zukünftigen (kernel-)Upgrades für weitere Arbeit sorgt. Und die Verwendung eines obsoleten Kernel kommt für mich auch nicht in Frage. Kann mir jemand weiterhelfen?
Folgende Hardware ist verbaut:
CPU(/GPU...): AMD Ryzen 5 5600G Mainboard: Gigabyte B550M DS3H (mit BIOS Version F14c aufgespielt) 32GB RAM G.Skill Aegis 3200 MHz Seagate Firecuda 520 SSD 500GB außerdem an den S-ATA Anschlüssen eine weitere SSD und zwei optische Laufwerke
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Boote bitte 21.04 Live und Zeige ip a
Ich will wissen, ob das ein Treiberproblem oder ein anderes Problem ist.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
Weevil schrieb: […] verbaut ist auf dem Mainboard soweit ich weiß der Realtek 8118 Chipsatz
Solange Du nicht sicher weißt, um welche Hardware es sich handelt, ist ein Herumspielen an den Treibermodulen nicht sinnvoll. Mit folgendem Befehl wird u.a. die PCI-ID der Ethernet-Hardware ermittelt. Mit Hilfe dieser ID ist der konkrete Chip in der Regel zu ermitteln. Zeige bitte:
lspci -nnk -d ::0200
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Andere Meldungen gab es nicht? Dein grep eth ist ungünstig da das Device ja als erstes direkt umbenannt wird...
|
Weevil
(Themenstarter)
Anmeldungsdatum: 24. September 2021
Beiträge: 4
|
Vielen Dank schonmal für die Antworten.
@DJKUhpisse: Hab' ich gemacht. Zunächst kam das hier raus:
xubuntu@xubuntu:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 18:c0:4d:98:99:fb brd ff:ff:ff:ff:ff:ff
inet6 fe80::ae72:7035:d1d2:f6a6/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Nach ein paar Minuten gab es eine Netzwerkverbindung und ich habe es nochmals probiert. Die Ausgabe war bis zur vorletzten Zeile identisch und dann folgendes:
[...]
inet6 2003:e1:2703:8b00:326b:2d85:ccfa:6ec8/64 scope global temporary dynamic
valid_lft 7138sec preferred_lft 1738sec
inet6 2003:e1:2703:8b00:3804:787e:ea80:9f93/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7138sec preferred_lft 1738sec
inet6 fe80::ae72:7035:d1d2:f6a6/64 scope link noprefixroute
valid_lft forever preferred_lft forever
@kB:
xubuntu@xubuntu:~$ lspci -nnk -d ::0200
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 16)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
Kernel driver in use: r8169
Kernel modules: r8169
@frostschutz: mir ist jedenfalls bei der Suche nach Einträgen zum Netzwerkadapter nichts weiter aufgefallen. Habe schon auch nach Begriffen wie "LAN" oder "r8118" u.Ä. gesucht. Aber wie gesagt: ich kann leider nicht von mir behaupten, dass ich wirklich wüsste, was ich da tue :-/
Ansonsten gibt es beim Systemstart hie und da ein Popup, es hätte einen "Fehler mit einer Systemanwendung" gegeben bzw. Ubuntu hätte einen "internen Fehler festgestellt". Da habe ich nicht im Detail darauf geachtet, in welchen Fällen das war, weil ich damit über die letzten Jahre bei verschiedenen Rechnern / Installationen immer wieder mal konfrontiert wurde und es eigentlich nie etwas war, dem nachzugehen sich wirklich gelohnt hat. Aktuell beschwert sich die frische 20.04 LTS Installation über einen "internen Fehler" mit "blueman-tray", weil eine Datei "blueman-tray-1000" nicht gefunden wird. Ich denke aber nicht, dass das für das Netzwerkproblem relevant ist.
Was ich jetzt erst bemerkt habe und mir schon eher nach einer möglichen Spur aussieht, ist, dass beim Start des Live-Systems kurz eine Fehlermeldung bezüglich "IOMMU" zu sehen war. Im dmesg habe ich dazu dann gefunden:
xubuntu@xubuntu:~$ sudo dmesg | grep IOMMU
[ 0.570504] pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
[ 0.572076] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
[ 2.804339] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
Könnte das etwas damit zu tun haben?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Der Treiber ist ok, sonst würde kein IPv6 gehen.
Bitte zeige nun vollständig incl. Prompt ip a
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
Weevil schrieb: […] xubuntu@xubuntu:~$ lspci -nnk -d ::0200
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 16)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
Kernel driver in use: r8169
Kernel modules: r8169
Ein Chip aus der RTL8168-Familie, die normalerweise durch den Linux-Modul r8169 gut unterstützt werden. Bei ganz neuen Varianten kann es helfen, den Treiber r8168 von Realtek zu verwenden. Realtek benutzt diesen zur Entwicklung, die irgendwann einmal direkt im Linux-Kernel bei r8169 landen. Allerdings ist es wohl in Deinem Fall sinnlos, den r8168 zu versuchen, weil:
Realtek stellt den r8168 nur für Linux-Kernel bis Version 5.6 zur Verfügung. Wenn Du damit experimentieren willst, musst Du auch einen solchen Kernel verwenden. Die sinnvollste Wahl im Ubuntu-Universum wäre der Ubuntu-LTS-Kernel 5.4 aus Ubuntu 20.04 LTS (nicht HWE!) oder der Ubuntu-Mainline-Kernel der Version 5.4. Das Chipdesign RTL8118 ist schon ziemlich alt und wird daher bereits lange vom r8169 unterstützt. Es ist nicht zu erwarten (gleichwohl auch nicht unmöglich), dass der Entwicklungsmodul r8168 für diesen Chip etwas neues bringt. Die Netzwerkhardware funktioniert ja, da das Protokoll IPv6 funktioniert.
Zeige aber bitte dennoch die Meldungen des Treibers vollständig:
uname -a
dmesg | grep -e 8169 -e 8168 Wie kommst Du überhaupt auf den RTL8118? Steht davon irgend etwas in der Dokumentation des Motherboards?
|
Weevil
(Themenstarter)
Anmeldungsdatum: 24. September 2021
Beiträge: 4
|
@DJKUhpisse: Sorry, ich verstehe nicht so ganz. Das war doch vollständig und der Prompt vom Live-System auch dabei: xubuntu@xubuntu:~$ ip a Habe zwischenzeitlich die Installation nochmal durchlaufen lassen und einen Verbindungsaufbau abgewartet, das Ergebnis sieht aber identisch aus:
boeck@boeck-PC:~$ sudo ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 18:c0:4d:98:99:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.178.20/24 brd 192.168.178.255 scope global dynamic noprefixroute enp3s0
valid_lft 863635sec preferred_lft 863635sec
inet6 2003:e1:272f:8b00:3330:ad28:6750:4d5/64 scope global temporary dynamic
valid_lft 6835sec preferred_lft 1349sec
inet6 2003:e1:272f:8b00:b14d:c23f:90ef:493b/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6835sec preferred_lft 1349sec
inet6 fe80::3dda:2c17:a135:f748/64 scope link noprefixroute
valid_lft forever preferred_lft forever
@kB: Die Info, es sei der RTL8118 verbaut, habe ich leider aus keiner Primärquelle: Gigabyte schreibt auf seiner Produktseite und auch im Handbuch nur von einem "Realtek ® GbE LAN chip (1000 Mbit/100 Mbit)". Die Angabe habe ich in verschiedenen Produktvorstellungs- bzw. -Test- Beiträgen gefunden, z.B. hier: https://www.amd3d.com/reviews/gigabyte-b550m-ds3h-motherboard-review/ oder auch, indem man auf dieser Seite https://premiumbuilds.com/compare-motherboards/ bei der Filter-Kategorie "LAN Chip" den RTL8118 (nicht RTL8118AS) auswählt. Ansonsten:
boeck@boeck-PC:~$ uname -a
Linux boeck-PC 5.11.0-16-generic #17-Ubuntu SMP Wed Apr 14 20:12:43 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
boeck@boeck-PC:~$ sudo dmesg | grep -e 8169 -e 8168
[sudo] Passwort für boeck:
[ 0.278870] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
[ 2.677686] libphy: r8169: probed
[ 2.677816] r8169 0000:03:00.0 eth0: RTL8168h/8111h, 18:c0:4d:98:99:fb, XID 541, IRQ 45
[ 2.677820] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2.678455] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 6.992559] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[ 7.192707] r8169 0000:03:00.0 enp3s0: Link is Down
[ 14.751151] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 14.816945] r8169 0000:03:00.0 enp3s0: Link is Down
[ 26.634553] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 26.634565] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 26.700618] r8169 0000:03:00.0 enp3s0: Link is Down
[ 34.639373] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 34.705627] r8169 0000:03:00.0 enp3s0: Link is Down
[ 51.991750] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 51.991768] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 52.058841] r8169 0000:03:00.0 enp3s0: Link is Down
[ 66.280714] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 66.280732] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 66.348024] r8169 0000:03:00.0 enp3s0: Link is Down
[ 83.057429] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 83.057447] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 83.124796] r8169 0000:03:00.0 enp3s0: Link is Down
[ 91.565457] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 91.565468] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 91.632290] r8169 0000:03:00.0 enp3s0: Link is Down
[ 105.587555] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 105.587574] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 105.653882] r8169 0000:03:00.0 enp3s0: Link is Down
[ 128.551577] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 10Mbps, check cabling!
[ 128.551595] r8169 0000:03:00.0 enp3s0: Link is Up - 10Mbps/Full (downshifted) - flow control off
[ 753.899013] r8169 0000:03:00.0 enp3s0: Link is Down
[ 756.526093] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[ 756.726402] r8169 0000:03:00.0 enp3s0: Link is Down
[ 765.952547] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 766.018427] r8169 0000:03:00.0 enp3s0: Link is Down
[ 782.241940] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 782.241955] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 782.307923] r8169 0000:03:00.0 enp3s0: Link is Down
[ 789.852306] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 789.920144] r8169 0000:03:00.0 enp3s0: Link is Down
[ 796.816821] CPU9 is up
[ 796.816840] smpboot: Booting Node 0 Processor 10 APIC 0x9
[ 796.816934] microcode: CPU10: patch_level=0x0a50000c
[ 798.683206] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[ 798.883306] r8169 0000:03:00.0 enp3s0: Link is Down
[ 805.650443] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 805.650454] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 805.716612] r8169 0000:03:00.0 enp3s0: Link is Down
[ 814.192740] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[ 814.380862] r8169 0000:03:00.0 enp3s0: Link is Down
[ 826.255115] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 826.255127] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 826.322332] r8169 0000:03:00.0 enp3s0: Link is Down
[ 834.240984] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 834.309518] r8169 0000:03:00.0 enp3s0: Link is Down
[ 840.936195] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 841.003041] r8169 0000:03:00.0 enp3s0: Link is Down
[ 851.274646] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 851.274665] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 851.340653] r8169 0000:03:00.0 enp3s0: Link is Down
[ 862.610321] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 862.610339] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 862.676595] r8169 0000:03:00.0 enp3s0: Link is Down
[ 872.587427] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 872.587444] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 872.654549] r8169 0000:03:00.0 enp3s0: Link is Down
[ 880.802396] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 880.802418] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 880.868886] r8169 0000:03:00.0 enp3s0: Link is Down
[ 889.184228] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
[ 889.251070] r8169 0000:03:00.0 enp3s0: Link is Down
[ 903.703758] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 903.703776] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 903.770153] r8169 0000:03:00.0 enp3s0: Link is Down
[ 918.965781] Generic FE-GE Realtek PHY r8169-300:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[ 918.965798] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full (downshifted) - flow control off
[ 919.031687] r8169 0000:03:00.0 enp3s0: Link is Down
Was den Hinweis check cabling! angeht: der Rechner ist tatsächlich über altes, nicht allzu hochwertiges festverlegtes Kabel an den Router angeschlossen, aber das sollte doch nicht zu den genannten Symptomen führen, zumal es ja bisher immer funktioniert hatte und frühere Überprüfungen keine Einbußen bzgl. der verfügbaren Bandbreite und keine Probleme mit der Signalqualität erkennen ließen?
Außerdem nochmal die Frage: dieser Fehler "Unable to read/write to IOMMU perf counter" - weiß da jemand näheres, ob das mit dem Problem zu tun haben könnte? Ich habe nämlich diesen Beitrag gefunden, wo ein Problem mit IOMMU wohl tatsächlich für Netzwerkprobleme mit einem Realtek RTL8118AS verantwortlich war: http://ideanist.com/2017/12/07/ubuntu-16-04-linux-biostar-b350gt5-realtek-rtl8118as-networking-working/ Ich habe an mehreren Stellen gelesen, Grund für instabile Verbindungen mit dem R8169 Treiber seien Konflikte bei den PCI Interrupts gewesen. Falls ich das halbwegs richtig verstehe, arbeitet die "I/O Memory Management Unit" ja irgendwo auf ungefähr diesem Gebiet. → https://de.wikipedia.org/wiki/IOMMU Das Vorgehen, was im verlinkten Beitrag beschrieben wurde habe ich ausprobiert und es hat insofern funktioniert, dass der Fehler "Unable to read/write to IOMMU perf counter" danach weg war (und es auch sonst eine andere Ausgabe von dmesg für die Suche nach "IOMMU" & "iommu" gab). Am Verhalten der Netzwerkverbindung hat sich aber nichts erkennbar verbessert.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Der Rechner hat IPv4 und IPv6.
Teste jetzt den Internetzugang und prüfe, ob der auch weiterhin IPv4 und IPv6 hat.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Weevil schrieb: Was den Hinweis check cabling! angeht: der Rechner ist tatsächlich über altes, nicht allzu hochwertiges festverlegtes Kabel an den Router angeschlossen, aber das sollte doch nicht zu den genannten Symptomen führen, zumal es ja bisher immer funktioniert hatte und frühere Überprüfungen keine Einbußen bzgl. der verfügbaren Bandbreite und keine Probleme mit der Signalqualität erkennen ließen?
Möglich ist das schon. Da kann die eine Netzwerkkarte auch empfindlicher sein als die andere. Eine einfache Möglichkeit das nachzuprüfen, wäre einen Switch dazwischen zu stellen und dein Gerät mit einem kurzen Patchkabel direkt an den Switch anzuschließen. Wenn das Kabel Switch--Router schlecht ist, kann dann immer noch die Verbindung (zum Internet etc.) abbrechen. Aber du bekommst keine Probleme auf der kurzen Strecke Mainboard--Switch und das ist dann das einzige, wofür sich der r8169 Treiber direkt interessiert.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Man kann z.B: mit bmon den Fehler-Zähler auslesen. Wenn der am Tag >10 ist, sage ich, ist was faul.
|
Weevil
(Themenstarter)
Anmeldungsdatum: 24. September 2021
Beiträge: 4
|
frostschutz schrieb: [...] Da kann die eine Netzwerkkarte auch empfindlicher sein als die andere. [...]
Tja, was soll ich sagen.... genau das scheint des Pudels Kernelversion zu sein. Ich hatte mir eigentlich nicht mehr davon versprochen, dem mal nachzugehen, als eine weitere Fehlerquelle ausschließen zu können, aber: Rechner abgebaut, alles zum Router geschleppt, angestöpselt – und siehe da: verbindet einwandfrei.
Da hatte ich wohl ein bisschen die Scheuklappen auf, weil ich schon zu Beginn meiner Recherche, ob das letztlich verbaute Mainboard für mich geeignet wäre, in einer Käufermeinung gelesen hatte, dass es Probleme mit den Linux-Treibern gegeben hätte (eigentlich auch, wie diese dann behoben wurden, aber den Beitrag trotz umfassendstem durchforsten der Browserhistorie nie wieder gefunden) ... So ganz befriedigend ist die Erkenntnis auch nicht, weil jetzt wohl doch wieder weitere Hardware nötig wird. Frische Kabel verlegen ist in der baulichen Situation kaum möglich, WLAN am Desktop PC ist mir normalerweise eher unsympathisch usw., aber wenigstens ist jetzt klar, was Sache ist.
Damit setze ich das Problem dann mal auf gelöst und danke euch allen hiermit nochmals für die Unterstützung.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Was für ein Kabel liegt da?
Dosen dazwischen?
Wenn ja wie verkabelt?
Mache Fotos.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
Weevil schrieb: […] boeck@boeck-PC:~$ sudo dmesg | grep -e 8169 -e 8168
[sudo] Passwort für boeck:
[ 0.278870] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
[ 2.677686] libphy: r8169: probed
[ 2.677816] r8169 0000:03:00.0 eth0: RTL8168h/8111h, 18:c0:4d:98:99:fb, XID 541, IRQ 45
[ 2.677820] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2.678455] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 6.992559] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[ 7.192707] r8169 0000:03:00.0 enp3s0: Link is Down
[ 14.751151] r8169 0000:03:00.0 enp3s0: Link is Up - 100Mbps/Full - flow control off
Mit der Software ist vermutlich alles in Ordnung. Es ist ein Hardware-Problem. Gemäß der "Link is down/up"-Orgie im Systemlog können sich der im Rechner verbaute Chip und der Chip der Gegenstelle über dieses Kabel nicht automatisch auf ein Übertragungsverfahren und eine Übertragungsgeschwindigkeit einigen. Dabei sind vermutlich alle drei beteiligten Komponenten technisch in Ordnung und funktionieren auch klaglos mit anderen Partnern, nur nicht in dieser Kombination. Abhilfen:
In die Verbindung Rechner-Router einen Repeater oder Switch einschleifen. Damit bekommt der Chip eine andere Gegenstelle, mit der es möglicherweise funktioniert. Oder: Die automatische Aushandlung der Übertragungsparameter abschalten und feste Werte vorgeben. Das geht mit ethtool oder per Einstellung im Verbindungsprofil für den NetworkManager oder auch per systemd-networkd. Wahrscheinlich wirst Du dann auf Giga-Ethernet verzichten müssen.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Erstmal die Verkabelung prüfen, denn direkt am Router geht ja alles.
|