Pi nicht mehr per Netzwerk erreichbar, aber aktiv

  • So, der erste Versuch der Übersetzung eines Kernels für den Pi auf meinem Arbeitsrechner ist gescheitert. Irgend etwas fehlt noch. Aber damit habe ich schon fast gerechnet. Jedoch ist das nicht das, was mich jetzt am meisten wundert, ich werde weitere Versuche unternehmen.


    Allerdings habe ich bei der Konfiguration gesehen, daß der Kernel für den Pi nur USB1 unterstützt, nicht USB1.1 und nicht USB2. Die kompletten Optionen für USB1.1 und USB2 sind überhaupt nicht vorhanden: die Module für EHCI und UHCI existieren nicht.


    Also ist der Pi wohl nur mit einem USB1-Hub ausgestattet. Das erklärt einerseits den schlechten Durchsatz auf dem Netzwerk und könnte außerdem ein weitere Ursache des "Mysteriums" sein.

  • Hallöle PInguin,



    ...
    daß der Kernel für den Pi nur USB1 unterstützt, nicht USB1.1 und nicht USB2. Die kompletten Optionen für USB1.1 und USB2 sind überhaupt nicht vorhanden: die Module für EHCI und UHCI existieren nicht.


    Also ist der Pi wohl nur mit einem USB1-Hub ausgestattet. Das ...


    ich fürchte, da bist Du schief gewickelt.
    Der RPi hat USB 2.0. Sonst würden uns ja alle, inkl. -> wikipedia <- anschwindeln. Naja, das mag vielleicht hin und wieder auf den einen oder anderen Anbieter zutreffen :fies: ... aber - wie gesagt - Wikipedia?
    Welche Kernel-Konfiguration hast Du verwendet bzw. wo hast Du die her?


    neugierige Grüsse,
    -ds-

  • Ich bin nach dieser Anleitung vorgegangen.


    Beim Befehl "make menuconfig" werden im Gegensatz zur Kernelkonfiguration auf meinem Arbeitsrechner keine Optionen für die Module für USB1.1 und USB2 angeboten. Für mich (als Laie) sieht das so aus, als ob diese Module aus dem Kernel entfernt wurden.

  • Hallo Dreamshader,



    Code
    1. Da hab' ich noch was im Hinterkopf, dass der RPi ja einen internen Hub hat von dem aber nur zwei Ports nach aussen geführt wurden. Die anderen Ports verwendet die CPU selbst ( z.B. für diesen USB2Ethernet Adapter ).


    Nach meinen Erfahrungen und Ausgaben von z.B. dmesg wird Alles, was am USB-Anschluss hängt, als eigenständiges USB-Gerät erkannt. Jeder USB-Adapter, jedes Y-Kabel, .... Aus den 2 USB-Ports können dann noch wesentlich mehr werden.



    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • So Leutz,
    ich glaube, langsam hab' ich für heute genug geschwafelt und Unsinn verzapft :) ...



    Ich bin nach dieser Anleitung vorgegangen.
    Beim Befehl "make menuconfig" ...


    Also die kenn' ich nicht und sie scheint ja auch nicht so 100%ig zu sein.
    Empfehlen kann ich Dir allerding -> diese <- Anleitung.
    Um die Konfiguration Deines laufenden Systems zu übernehmen machst Du vor dem Compiler-Lauf ein

    Code
    1. zcat /proc/config.gz > .config

    .
    Abr ich glaube, das steht auch in der verlinkten Anleitung.


    Ach ja, Andreas: das mit dem internen USB-Hub stimmt schon. Und Y-Kabel werden doch nicht angezeigt, Du Schlawiner ... willst Du hier unbedarfte Besucher in die Wüste schicken :)
    ...
    Bis später, ich wollte noch meine Ergebnisse dieses sysbench posten.
    -ds-

  • Hallo Dreamshader,


    hier ein Auszug aus meinem dmesg:



    An meinem Raspberry hängt nur einem USB-Port etwas. Der andere Port ist nicht belegt. Ein USB-Hub ist auch nicht angeschlossen.
    Daraus geht hervor, dass der Raspberry jede am USB-Hub angeschlossene Komponente inkl. Adapter etc. erkennt.


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo zusammen,
    hier mal meine Versuche auf der RPi B-Variante mit


    Code
    1. Linux raspberrypi 3.10.36+ #664 PREEMPT Mon Apr 7 14:01:14 BST 2014 armv6l GNU/Linux


    als Betriebssystem.
    Beim ersten Test,

    Code
    1. sysbench --test=cpu --cpu-max-prime=20000 run


    dem CPU Bench kommt folgendes heraus:



    top sagt dazu:


    Ruckler sind schon zu spüren (wen wunderts), allerdings ist der RPi nicht abgestürzt. Ich hab keinen Desktop in Benutzung und auch weder Maus noch Tasten angeschlossen. Zum Verhalten dieser Teile kann ich daher im Moment leider nichts beitragen.


    Nach Aufsetzen eines NFS-Servers habe ich mich an die Benchmarks für Datei-Operationen herangemacht.
    Also, nach Einhängen des NFS-Laufwerks ergibt sich folgendes Bild auf dem Server:
    mount zeigt:


    df -m zeigt:


    ifconfig zeigt:


    und auf dem Client zeigt mount:


    df -m zeigt:


    ifconfig zeigt:


    Während des Laufs sagt top auf dem Server:


    und auf dem Client:


    root@raspberrypi:/mnt# time sysbench --test=fileio --file-total-size=2G --file-num=16 prepare
    sysbench 0.4.12: multi-threaded system evaluation benchmark


    16 files, 131072Kb each, 2048Mb total
    Creating files for the test...


    real 26m26.412s
    user 0m0.220s
    sys 0m15.070s
    root@raspberrypi:/mnt#


    Nach dem Test zeigt mount auf dem Server:


    df -m zeigt:


    und ifconfig zeigt:


    und auf dem Client zeigt mount:


    df -m zeigt:


    ifconfig zeigt:



    Der Server meckerte während des Laufs ziemlich heftig:


    Die Meldung kommt gefühlte 1000 mal. Der Client hingegen schweigt still :) ...


    Dieser Endstand ist jetzt de Ausgangs-Situation für den zweiten Bench mit Datei-Zugriffen.


    root@raspberrypi:/mnt# sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 --file-num=16 run
    sysbench 0.4.12: multi-threaded system evaluation benchmark


    Ergebnis:


    Während dieses zweiten Benchmark gibt ein top auf dem Server


    aus und der Client meint während des Laufs bei der Eingabe von top:


    Tja, und last but not least die "Statistik" nach dem Lauf.
    Beim Server zeigt mount an:


    df -m zeigt:


    ifconfig zeigt:


    und beim Client zeigt mount:


    df -m zeigt:


    ifconfig zeigt:


    Jetzt hoffe ich, dass der ganze Kram hier auch irgendwie hilfreich ist.
    War jedenfalls mal eine nette Abwechslung zu meinen Displays ...


    cu,
    -ds-

  • Na holla dreamshader :thumbs1:


    Prima, na da lässt sich je etwas entnehmen:
    Das Ruckeln kommt, weil die Konsole nicht mehr jedes Paket bekommt, offenbar timing-Probleme in dem überlastetem RPi... das ist "normal", das Log hast du ja gefunden :lol:


    Wie es aussieht, hast du auch keine IP-Abhänger gehabt... nicht mal Paketverluste... bei mir haben sich die Paketverluste auf >1400 angehäuft... naja, das Timing klappt dann nicht mehr so ganz geschmeidig... Ich habe auch keinen lupenreinen WLAN-Kanal, da hängen noch andere Mieter mit drauf bzw. dicht daneben... keine Aufregung..


    Nach meinen aktuellen Messungen sehe ich meine Vermutung erhärtet... Aber mal zum Test:


    Messaufbau:
    Netzteil: wie in Post 23 beschrieben
    Strommessung: (in den Bildern rot): mit 0,12 Ohm Shunt in der Masseleitung der Versorgungsspannung
    Spannungsmessung: (in den Bildern gelb): vom gleichem Massepunkt wie Strommessung nach +5V vor den Shunt
    Raspi: WLAN, 3 LEDs (aus), 3 DS1820 an 1W (unbenutzt)


    1. Messung (Leerlauf)
    wie in Post 25 unverändert (warum auch?)


    2. Messung (100% CPU Last wie gestern beschrieben mit sysbench)
    Der "Basis"-Strom erhöht sich "geringfügig" ca. 370mA...


    [IMG:http://s7.directupload.net/images/140413/ytpqeywt.png%20%20]


    der Pulsspitzenstrom liegt nun bei ca. 753mA.


    [IMG:http://s14.directupload.net/images/140413/s2jza8ss.png]


    Das ist keine dramatischen Erhöhung, jedenfalls nicht so, wie ich erwartet hätte. Die CPU scheint also nicht der wirkliche Stromfresser zu sein...


    Aber nun mal was Interessantes: Die Spannungen:
    Mein NT liefert etwas über 5V, genauer ca. 5,08V als "Grundspannung"


    [IMG:http://s1.directupload.net/images/140413/ffykwbff.png]


    Wenn die Pulse da sind, erhöht sich die Spannung !!!
    Ich diskutier das dann mal am Ende...


    [IMG:http://s1.directupload.net/images/140413/cgmhsa45.png]


    3. Messung: hohe WLAN-Load durch Anlegen von 16 File a 128MB auf einem remote stehenden NAS LW. (per mount verbunden)
    Der Grundstrom erhöht sich auf fast 500mA, WLAN zieht Strom :D


    [IMG:http://s1.directupload.net/images/140413/r5thf4k5.png]


    Und: Der Spitzenpegel nähert sich 860mA (!), war teilweise drüber, aber diese Messung hab ich nicht als Bild...


    [IMG:http://s14.directupload.net/images/140413/8rcti5g7.png]



    Ich schick diesen Post jetzt mal ab (wegen max. 10 Bilde/Post) und schreibe meine Einschätzung dann weiter...

  • Es gibt eine gute und eine schlechte Nachricht.


    Zuerst die Gute: wir sind mit diesem Problem definitiv nicht alleine. Auf https://github.com/raspberrypi/linux/issues gibt es etliche Hilferufe wegen abgerissener Netzwerk- und USB-verbindungen.


    Die schlechte Nachricht: dieser Fehler existiert wohl schon seit 2012, denn schon da gab es die ersten, die dieses Phänomen beobachteten.


    Beispiele:
    https://github.com/raspberrypi/linux/issues/470
    https://github.com/raspberrypi/linux/issues/136


    Ich habe jetzt mal wie in einigen der Beiträge dort in /boot/cmdline.txt folgende Einträge hinzugefügt:


    Code
    1. smsc95xx.turbo_mode=N dwc_otg.speed=1


    Der zweite Parameter setzt den USB-Chip auf USB-1.1-Geschwindigkeit, also max 12MBit. Damit reduziert sich zwar auch die maximale Netzwerkgeschwindigkeit auf 10MBit, und Geräte, die USB-2 benötigen, wie z.B. USB-Kameras, laufen damit nicht an den USB-Ports.


    Da ich aber keine solchen Geräte an dem Pi hängen habe, und meine Außenleitung sowieso nicht mit 100MBit mithalten kann, ist diese Reduzierung für mich in Ordnung. Ob sie überhaupt etwas bringt, müssen die nächsten Stunden zeigen.


    Bisher (seit ca 3 Stunden) habe ich danach noch keinen Ausfall wieder gehabt. Im Gegenteil: ich habe sogar irgend wie den Eindruck, als wenn der Pi besser läuft: im Syslog tauchte bisher kein einziges "lost connection" o.ä. auf, und selbst der Lighttpd scheint die Wiki-Seiten schneller auszuliefern.


    Ich weiß, daß das eigentlich nicht sein kann, aber das ist mein subjektiver Eindruck: die Verbindungen erscheinen schneller. Selbst bei der Verbindung per ssh (mit Pub-Key) scheint es schneller zu gehen, bis der Cursor da ist. Und "top" zeigt weniger Auslastung an, wenn ich mich mit OwnCloud verbinde.


    Vielleicht erscheint mir die Kiste auch nur schneller, weil ich müde bin. Werde jetzt erst mal darüber schlafen und morgen mal in die Logdateien gucken.

  • Die Spannung hat sich weiter erhöht...


    [IMG:http://s1.directupload.net/images/140413/ktei6qcp.png]


    und erreicht in den Spitzen wieder 5,4V


    [IMG:http://s7.directupload.net/images/140413/7me4enlo.png]


    Der Vollständigkeit halber auch mal der Abstand der Peaks: 17,3 mySec, konstant (!)


    [IMG:http://s1.directupload.net/images/140413/9xcqunhg.png]
    So, was will uns das alles sagen?


    Offenbar habe ich ein NT, das progressiv regelt (also eigentlich falsch) und bei Lasterhöhung die Spannung bis auf 5,4V anhebt.
    In wie weit das auf Dauer gut geht, wage ich nicht zu beurteilen, in meinem Szenario tauchen diese Lasten nicht auf, insofern werde ich lediglich einen Kühlkörper spendieren und gut.


    Die Frage, die jetzt im Raum steht ist allerdings: Was machen andere (Handy-) NT bei den Pulsen? Spannung erhöhen, einbrechen oder ideal wegregeln?


    Und damit ergibt sich ein Indiz, dass evtl. eine einbrechende Spannung über den Linearregler bis zur CPU oder dem USB/Ethernet-Chip durchschlägt hier Fehler induziert.


    Nun müßte man diese Messung mal mit einem NT der instabileren Fraktion machen... am besten dann mit Speisung über MicroUSB ...


    Jo, ich hau mich erstmal hinne.... nächtle...

  • Moin!


    So, ich bin (halbwegs) ausgeschlafen, und der Pi läuft seit ca. 12 Stunden mit den von mir hinzugefügten Parametern in /boot/cmdline.txt ruhig und ohne Macken. Im syslog taucht seit dem keine einzige Meldung auf, die auf Probleme mit dem Netzwerk und/oder USB hinweisen. Vorher hatte ich sehr häufig diese Meldungen im syslog:


    Code
    1. ERROR::dwc_otg_hcd_urb_enqueue:515: Not connected


    und


    Code
    1. smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup



    Die sind seit gestern Nacht nicht wieder aufgetaucht. Außerdem habe ich in der letzten Stunde intensiv mit dem auf dem Pi laufenden DokuWiki gearbeitet und ich fühle, daß es besser "flutscht". Ich weiß nicht, wie ich es ausdrücken soll, aber es geht einfach besser. Vorher musste ich manchmal mehrere Sekunden warten, bis nach dem Klick auf "Speichern" der Vorgang auch wirklich abgeschlossen war. Das geht jetzt definitiv und messbar schneller!


    Eine mögliche Erklärung dafür wäre, daß der verbaute USB-Chip nicht wirklich für den Betrieb im High-Speed-Modus geeignet ist. Ich weiß aus Erfahrung, daß vieles, was sich auf dem Markt befindet, das Label "USB 2.0 High-Speed" nicht wirklich verdient hat. Die Hersteller nehmen meistens die billigsten Chips, die unter Laborbedingungen und mit großzügigen Runden in den Berechnungen gerade so eben die Spezifikation erfüllen, nur, damit sie sich erdreisten können, auf die Verpackungen "USB 2.0 High-Speed" zu drucken, und weil sie wissen, daß sie keine juristischen Konsequenzen fürchten müssen.


    Am krassesten macht sich das bei USB-Speicher bemerkbar, aber ich habe auch schon PCI-Karten in der Hand gehabt, mit denen ältere Rechner mit USB-2.0 nachgerüstet werden können, die aber noch nicht einmal den USB-1.1-Standard schaffen. Damit einen Scanner zu betreiben ist dann eine Tagesaufgabe. :(


    Ich will jetzt nicht sagen, daß die Hersteller des Raspberry "geschummelt" haben. Meistens ist es so, daß die Hersteller von PC-Harware eher von den Chip-Herstellern, also den Zulieferern, betrogen werden. Nicht selten wird in der laufenden Produktion sogar völlig andere Ware geliefert, als während der Entwicklung des Endproduktes für die Testzwecke zur Verfügung gestellt wurde. Oder die Produktions-Sorgfalt wurde aus Kostengründen heruntergefahren.


    Wie dem auch sei: wenn es daran liegen sollte, daß der USB-Chip nicht geeignet für den Betrieb im High-Speed-Modus ist, wäre das eine Erklärung für die Ausfälle. Und auch für den besseren Datendurchsatz beim Ausliefern von Web-Seiten, denn weniger Datenfehler auf dem Bus bedeutet, daß weniger Wiederholungen nötig sind, und das wiederum bedeutet im Endeffekt höhere Effizienz. Was nützt ein Formel-1-Rennwagen, der alle 50 Meter ausgeht? Den kann ich mit einem konstant fahrenden Trabbi locker ausstechen!


    Zentris: könntest Du mit Deinem Ozzi-Guck vielleicht dahingehend mal Messungen machen? Ich bin kein richtiger Elektroniker, aber ich bin sicher, das man das messen können muss.


    Kann es nicht sogar sein, daß wir Ursache und Wirkung vertauscht haben? Bisher sind wir davon ausgegangen, daß die Spannungseinbrüche den USB-Chip lahmlegen. Kann es nicht auch umgekehrt sein, daß die Spannungsspitzen (oder Lastspitzen) das Ergebnis der Datenkollisionen auf dem Bus sind, weil der Chip kein High-Speed verträgt?


    Für mich als Nicht-Elektriker hört sich das logisch an. Aber ich lasse mich da gerne eines Besseren belehren.

    Einmal editiert, zuletzt von PInguin ()

  • Nach über 20 Stunden Betrieb mit gedrosseltem USB-Chip kann ich eine positive Bilanz ziehen: ich habe heute nicht nur mit dem Wiki auf dem Pi gearbeitet, sondern auch mit apt viele Pakete installiert, deinstalliert, neu installiert, wieder deinstalliert, wieder neuinstalliert, usw, bis die Leitung glühte. Zwischendurch immer den Cache geleert, damit apt die Sachen auch jedesmal neu runterladen muss. Und kein einziges mal hat mich der Pi dabei angeschwiegen!


    Das Netzwerk ist stabil, und im syslog stehen seit dem Neustart genau 9 (in Worten: neun) neue Zeilen. Davon sind 3 von ddclient, der die IP beim DynDNS-Dienst alle 5 Stunden erneuert hat, 5 Zeilen sind von Postfix, der eine Nachricht versendet hat, und eine, die erste, ist die Startmeldung vom Syslogd selber.


    Vor diesen Boot-Parametern hatte ich mehrere hundert Einträge pro Tag im Syslog, davon 99% Meldungen vom USB-System, daß neue Geräte gefunden wurden, daß Verbindungen abgebrochen sind, usw.


    Für mich sieht es sehr danach aus, daß "das Mysterium" mit dem Drosseln des USB-Chips beendet ist!


    Natürlich kann diese Drosselung nicht die letztendliche Lösung sein, sondern höchstens eine Linderung der Symptome. Aber ich glaube, jetzt haben wir einen festen Ansatzpunkt, an dem man gezielt weitersuchen kann.


    Bracew, Andreas: probiert es doch bitte auch einmal mit diesen Bootparametern aus und berichtet uns dann, ob es etwas gebracht hat.


    ______


    Ergänzung 15.04.14, 15:30h:


    Auch am Tag 2 nach dem Hinzufügen der Boot-Parameter habe ich noch keinen Ausfall des Netzwerkes erlebt! Der Pi läuft immer noch stabil, egal, wie sehr ich das Wiki und die OwnCloud darauf in Anspruch nehme!


    ________
    Ergänzung 2, 15.04.14, 19:00h:
    Also mein Pi läuft jetzt mit stabiler Netzwerkverbindung. Sobald ich den Parameter dwc_otg.speed=1 aus der cmdline.txt entferne, übersteht das Netzwerk nicht mal das erste "apt-get update". Das ist beliebig reproduzierbar!


    Leider habe ich jetzt das Problem, daß weder die USV, noch die Maus, die ich zum Runterfahren und Neustarten angeschlossen habe (mit triggerhappy), erkannt werden. Irgendwas ist ja immer. ;-)


    Als nächstes werde ich also probieren, ob ich die Peripherie-Geräte wieder ans Laufen kriege, wenn ich einen aktiven USB-Hub dazwischen klemme.

    Einmal editiert, zuletzt von PInguin ()

  • Faszinierend ;) :denker: :denker:


    Das dieser "Patch" bei dir funktioniert (mit den Kollateralschäden) ist schon etwas "gespenstisch"...


    Hast du noch einen andere RPi, an dem das reproduzierbar ist?


    :angel:
    Kann es sein, dass du Strom aus nicht genfreiem Anbau bekommst und dein Atomstromfilter nicht ordnungsgemäß gereinigt wurde, so dass die Hyperion-Schwingungen III.Ordnung in Blafasel-Resonanz mit dem Subkutangerüst des RPi kommen, so dass die Binärordnung der Bits im Speicher azyclisch permutieren ?
    Liegt ja fast auf der Hand :cool:
    :angel:


  • Faszinierend ;) :denker: :denker:


    Ja, Mr. Spock!


    Zitat


    Das dieser "Patch" bei dir funktioniert (mit den Kollateralschäden) ist schon etwas "gespenstisch"...


    Wieso gespenstisch? Nach dem, was ich darüber gelesen habe, scheine ich nicht der erste zu sein, bei dem dieser Parameter Wirkung zeigt.


    Zitat


    Hast du noch einen andere RPi, an dem das reproduzierbar ist?


    Nein, ich habe nur einen Pi, kein Pi-Pi... :lol:


    Zitat


    :angel:
    Kann es sein, dass du Strom aus nicht genfreiem Anbau bekommst und dein Atomstromfilter nicht ordnungsgemäß gereinigt wurde, so dass die Hyperion-Schwingungen III.Ordnung in Blafasel-Resonanz mit dem Subkutangerüst des RPi kommen, so dass die Binärordnung der Bits im Speicher azyclisch permutieren ?
    Liegt ja fast auf der Hand :cool:
    :angel:


    Ich habe jedes Elektron und jede Elektronin einzeln aus biologisch abbaubarer Bodenhaltung bezogen und mit dem Fluxkompensator den Spin gleichgerichtet. Reicht das?

  • Hallo zusammen,


    ich muss gestehen, dass ich das Thema etwas überflogen habe, aber wohl geschlussfolgert habe, dass es keine eindeutige Lösung für das Problem gibt.


    Ich hatte damals mit der Rev 1 häufiger WLAN Abbrüche, die auch nur durch einen Neustart zu beheben waren.


    Nun hatte ich mit der Rev 2 schon ewig lange dieses Problem nicht mehr. Letzte Woche habe ich allerdings mein ewig vorhandenes System von einer 8GB SD Karte auf eine 16 GB SD Karte überspielt
    und seitdem wieder mit den WLAN Abbrüchen zu kämpfen. Am Setup, Netzteil, Hardware, etc hat sich gar nichts geändert. Nichtmal der physische Standort des Pi.


    Nach unbestimmter Zeit, meldet mit Putty, dass die Verbindung weg sei. Im Router sehe ich dann eine tatsächliche Abmeldung aus dem WLAN. Ca. 1-2 Minuten nach dem Abbruch ist der
    Pi allerdings wieder erreichbar.


    Merkwürdig, oder?

  • Das er sich wieder verbindet, hängt vermutlich mit dem ifplugd - Daemon zusammen: Du wirst dhcp eingestellt haben und der Daemon versucht, nach der Trennung nach einer Weile wieder ein DHCP Lease zu bekommen.
    Offenbar klappt das, weil die Interface-Konfiguration nicht verloren gegangen ist.
    Bei anderen geht diese verloren (Thema USB-Reconfiger) und die eth0/wlan0-Konfiguration ist weg.


    Hast du mal in die Logs geschaut, was die Ursache des Disconnects war?


    ifplugd - Daemon:
    Es gibt ja hier im Forum den Tip, diesen Daemon zu deaktivieren, was bei einigen ja offenbar zielführend war, mir sich jedoch nicht erschließt: Ich tippe in diesen Fällen immer auf anderweitige Konfigurationsfehler... aber naja...

  • Moin Zentris,



    ...
    ifplugd - Daemon:
    Es gibt ja hier im Forum den Tip, diesen Daemon zu deaktivieren ...


    also Konfigurationsfehler? Das wäre aber dann der pure Zufall, wenn alle deren Fehlerbild mit der Deinstallation des ifplugd verschwunden ist, die gleichen Konfigurationsfehler haben.
    Ich brauch ihn nicht, er stört, ... also weg damit und Ruhe :) ...


    Schönen Tag noch,
    -ds-

  • Bei mir läuft er auf _allen_ RPs "und das ist gut so ", er tut.


    Warum nicht Konfigurationsfehler?


    "Millionen Fliegen können nicht irren?" :lol:


    Ich lese recht oft/viel diverse "tut" im Netz und oft stehen da so Sachen drin, die, wenn schon nicht falsch, so doch nicht korrekt sind... oder zumindest nicht schaden, aber auch nicht nutzen - Seiteneffekte? ... :angel:


    Es gibt ja bei Konfigurationsfehlern bekanntlich verschiedene Ausprägungen:
    1) Fehler fällt sofort auf, weil entweder das Programm den Fehler "entdeckt" oder das Programm totalen Mist macht.


    2) Fehler fällt nicht gleich auf, aber mit der Zeit, weil irgendwas anderes nicht so funktioniert, weil Vorrausetzungen fehlerhaft (Bsp: iptables falsch - keine Zugriff über port xyz - natürlich erst, wenn man von ausserhalb drauf zugreifen will)


    3) der Fehler fällt gar nicht auf: jedenfalls nicht direkt. Weil erstmal alles tut. Bzw. eigendlich nicht alles, aber nur manchmal, nicht reproduzierbar... ist auch nicht wirklich reproduzierbar, weil abhängig von ganz bestimmten Vorrausetzungen (WLAN: Pegelstärke, Signal/Rauschabstand, ab der der Empfänger nicht mehr will, Nebensprechen wegen benachtbarter Kanäle, Last auf der Leitung, Spannungsschwankungen)


    Ich hatte mal den Fall, dass ein Filesystem immer voll lief, weil die Logs kein "housekeeping" hatten. Ging bis zum Systemstillstand...
    Dann wurde ein Script eingerichtet und per cronjob regelmäßig gestartet... der sollte dann aufräumen... hm, ja, leider wurden da freie Byte und freie Blockanzahl bei der Berechung durcheinander gebracht... naja...:mad_GREEN:


    Aber wie wir ja wissen: "Bei Nebenwirkungen fragen Sie Ihren Arzt oder Therapeuten..." :lol:

  • Hallo zusammen,


    jetzt habe ich einige Tage hier nicht mehr reingeschaut - aber es hat sich wieder mal viel ereignet.


    PInguin : Die Drosselung des USB-Chips in einer Weise, dass er Maus / Tastatur nicht mehr erkennt, ist für mich keine Lösung. Andererseits ist es interessant, dass das Mysterium auf diese Weise bei Dir verschwunden zu sein scheint.


    Ich habe vor ein paar Tagen zwei neue Raspberries geschenkt bekommen (ja, bisher wurden mir alle geschenkt - auch von Firmen, damit ich damit irgendwas Sinnvolles anstelle).


    Der eine verfügt über eine SD-Karte mit vorinstalliertem Raspbian Wheezy (Version: liefere ich hier nachher nach) ist über GPIO an ein LCD-Display angeschlossen. Demzufolge muss das Teil ein wenig mehr Strom abgeben als das andere Modell vorher.


    In den Stunden, in der das Teil am Netz hing, hat sich kein Mysterium ereignet.



    Bei dem anderen werde ich in den kommenden Tagen die brandaktuelle Version von Raspbian installieren und dann meinetwegen auch mit Pinguin's Bootparametern experimentieren.


    Aber Nichterkennen von USB-Standardhardware, die keinen nennenswerten Beitrag zum Datentransfer beisteuert, ist für mich keine Lösung. Meine Software-Lösung fängt das Mysterium zuverlässig ab - wie gesagt, mir reicht das erstmal.


    :s :s


    Was mir gerade einfällt - und mich beginnt sehr nachdenklich zu machen: Ich bin ja an eine 46kB-Leitung angeschlossen. Diese maximal ca. 46.000 Bits/s, die da durch die Leitung schlendern, sind ja gerade mal 0,5 Promille, die die sonstige Hardware erlaubt. Das ist für mich auch nichts, was ich als große Belastung des Systems USB-LAN-Chip einstufen würde.
    :s


    Fortsetzungen folgen ...


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • ...
    Warum nicht Konfigurationsfehler?
    ...


    Nun ja, prinzipiell gebe ich Dir ja recht ... da ist vermutlich irgend etwas anderes im Argen.
    Aber in diesem Fall habe ich keine Lust Ursachenforschung zu betreiben und halte mich an die alte IT-Weisheit "Nichts läuft so gut und so lange wie ein Provisorium" ...


    cheers,
    -ds-