Beiträge von altamira

    Vielen Dank für die zahlreichen Antworten. Habe jetzt einiges ausprobiert:


    - neues Firefox-Profil: keine Verbesserung
    - Cache in FF gelöscht: keine Verbesserung
    - Alle Addons deaktiviert: keine Verbesserung
    - Proxy: Weder im System noch in FF eingestellt
    - Firewall: deaktiviert (Yast)


    IPv6:


    - ist aktiv
    - CND (collectNWData.sh) gibt einen Hinweis, dass dies Probleme machen könnte: CND0230W: IPV6 enabled and may be the reason for network problems 
    - ipv6-test.com und test-ipv6.com geben unter Chrome schnelle Ergebnisse mit hoher Punktzahl:
    . IPv6 supported, native IPv6
    . SLAAC no, ICMP filtered, Hostname none
    . Browser: IPv6, Fallback to IPv4 in < 1 second
    . DNS4 + IP6 Reachable, DNS6 + IP4 Reachable, DNS6 + IP6 Reachable


    - Bei FF:
    . IPv6 supported, native IPv6
    . SLAAC no, ICMP filtered, Hostname none
    . Browser: IPv6, Fallback to IPv4 in 8 seconds
    . DNS4 + IP6 Reachable, DNS6 + IP4 Reachable, DNS6 + IP6 Reachable


    test-ipv6.com zeigt für beide Browser folgende Ergebnisse:

    Test mit IPv4 DNS-Eintrag Okay (0.042s) verwende ipv4
    Test mit IPv6 DNS-Eintrag Okay (0.039s) verwende ipv6
    Test mit Dual Stack DNS-Eintrag Okay (0.073s) verwende ipv6
    Test mit Dual Stack und große Pakete Okay (0.040s) verwende ipv6
    Test IPv4 ohne DNS Okay (0.064s) verwende ipv4
    Test IPv6 ohne DNS Okay (0.068s) verwende ipv6
    Test große IPv6-Pakete Okay (0.107s) verwende ipv6
    Test ob der DNS-Server des ISP IPv6 unterstützt Okay (0.069s) verwende ipv6
    IPv4-Dienstleister finden Okay (0.135s) verwende ipv4 ASN 29562
    IPv6-Dienstleister finden Okay (0.109s) verwende ipv6 ASN 29562


    Das Problem ist also nicht IPv6 per se (wird vom ISP, Betriebssystem und Router voll unterstützt), sondern die Response-Zeiten in Firefox. Die Variable network.http.fast-fallback-to-IPv4 in FF ist bereits auf "true" gesetzt. Leider weiß ich nicht, wie ich die Fallback-Zeit weiter verbessern kann.


    Das Deaktivieren von IPv6 in FF über network.dns.disableIPv6 führt übrigens zu keiner Verbesserung.

    Hallo liebes Forum,



    vielleicht weiss ja jemand von Euch Rat. Ich verwende ein stets aktualisiertes Tumbleweed (KDE). Mein Internetprovider ist Unitymedia, ich gehe mit einer Fritzbox Cable ins Internet. Mein Computer ist via Netwerkkabel mit der Fritzbox verbunden.


    Seit einigen Wochen fällt mir folgendes auf: Webseiten brauchen ewig, bis sie endlich unter Firefox (meinem bevorzugten Browser) angezeigt werden. Das eigentliche Laden geht gewohnt schnell, es dauert nur lange, bis die Seiten nach Eingabe von Firefox erkannt und verarbeitet werden. Das gleiche Phänomen tritt unter Konqueror und Rekonq auf.


    Verwende ich Chrome, ist der Seitenaufruf blitzschnell, so wie vor einiger Zeit auch bei Firefox.


    Was ich schon versucht habe:


    - Fritzbox zurücksetzen auf Werkseinstellungen -> kein Effekt
    - Firefox zurücksetzen -> kein Effekt
    - Löschen der Netzwerkverbindung in KDE, neu verbinden -> kein Effekt
    - Überprüfen der Ping-Zeiten: Namensauflösung dauert sehr lange, bei Eingabe von IP-Adressen aber gewohnt schnell
    - Ändern der DNS-Server auf der Fritzbox -> Kein Effekt, auch mit Googles DNS-Servern nicht
    - Überprüfen der Proxy-Einstellungen: Kein Proxy bei den KDE-Systemeinstellungen oder im Firefox eingestellt


    Vielleicht weiss jemand Rat. Was macht Chrome anders/besser als Firefox?



    Viele Grüsse




    altamira

    Hallo kinoe,


    bin froh, dass ich nicht allein bin. Seit gestern funktioniert KDE in Tumbleweed nach einem Update nur seh eingeschränkt und stürzt auch ab. Gleiches Fehlerbild: Berechtigungen scheinen nicht zu passen, Environment-Variablen seien nicht gesetzt (ich konnte z.B. nicht mehr Yast benutzen) usw.


    Hoffe, das Problem löst sich zeitnah durch ein Update. Bin ehrlich auch ratlos, wo ich überhaupt ansetzen soll...


    Gruß altamira

    Nein, auch mit Syslevel 3 ging es nicht.


    Ich habe das jetzt ganz anders gelöst:


    - Im BIOS IOMMU deaktiviert
    => System lässt mich wieder rein, startet aber nicht sddm
    - blkid, UUID Einträge in der fstab angepasst, seitdem läuft es wieder (/home ist auf einem LUKS-verschlüsselten Volume)


    Fazit: Mit Kerneln ab 4.2 aufwärts gibt es bei einigen AMD-Chipsätzen Probleme mit der IOMMU-Implementierung. Nach Abschalten im BIOS geht es wieder. Virtualisierung betreibe ich nicht, also sollte ich auch keine Nachteile dadurch haben.


    Wenn es upstream einmal geflickt ist, kann ich die BIOS-Option wieder aktivieren.

    Hallo Sauerland,


    mit so schneller Antwort habe ich gar nicht gerechnet, herzlichen Dank. Da 4.1 auch noch gehen sollte, werde ich von einem Leap-Lifesystem chrooten und meine Erfahrungen berichten. Dauert allerdings wahrscheinlich bis zum Wochenende.


    Gruß Alexander

    Liebes Forum,


    ich habe mein bestehendes 13.2 auf Tumbleweed geupdated (fresh install). Leider verträgt sich meine Hardware (AMD Trinity Fusion auf FM2A55M-DGS) nicht mit neueren Kerneln >4.1. Dazu gibt es auch einen Bugreport:


    Bug 108711 – AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.1 domain=0x0000 address=0x0000000100000840 flags=0x0070]


    In Folge des Bugs bleibt TW während des Bootvorgangs hängen.


    Meine Frage: Wie kann ich bei TW den Kernel auf eine Version meiner Wahl downgraden? Mit chroot wäre ich halbwegs vertraut, ich weiß nur nicht, wo ich den passenden Kernel herbekomme.


    Vielen Dank im voraus für Eure Unterstützung.


    Gruß Alexander