FHEM Forum

Hallo!

Ich bin hier echt am verzweifeln!  :(
Bin absoluter Neuling, was FHEM angeht und habe mein Problem bereits im KNX-Bereich von diesem Forum (http://forum.fhem.de/index.php/topic,19260.0.html) gepostet, aber da hat sich bis jetzt noch niemand gemeldet. In der Hoffnung, dass es nicht KNX spezifisch ist frage ich hier noch mal nach, ob jemand mir helfen kann, den Fehler zu finden, warum sich FHEM nach einigen Stunden einfach aufhängt / abstürzt.   :o
FHEM habe ich auf einem Raspberry PI nach dieser Anleitung (http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/) installiert, KNX nach der Anleitung in der FHEM-Wiki (http://www.fhemwiki.de/wiki/EIB_/_KNX). Die KNX-Busankopplung erfolgt über TPUART USB Modul von busware.de (http://busware.de/tiki-index.php?page=TUL).
Habe alle Logfiles deaktiviert, um auszuschließen, dass irgendein "Datenstau" (ist nur eine langsame Class 4 SD-Karte im Pi)  beim Schreiben der Logfiles zum Absturz führt.

Der Absturz zeichnet sich dadurch aus, dass die Webseite von FHEM weder für den PC (Port 8083), Smartphone (Port 8084) noch Tablet (Port 8085) aufgerufen werden kann.
Die grüne Status-LED des TPUART EIB/KNX blickt nur sehr schwach in ca. 500ms Rythmus. Der Pi ist über das Netzwerk erreichbar und kann Über einen SSH-Tunnel neu gestartet werden.
Nach einem Reboot leuchtet die Status LED wieder hell und FHEM ist auch wieder erreichbar.
Ist das Logfile aktiv sieht man, wann FHEM ungefähr ausgestiegen ist, da die zyklischen Statusmeldungen in der Form
2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:02:22 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:02:22 3: TUL EIB refused message: 9c11142205e20080ff
2014.01.25 15:03:14 2: EIB EIB_4206 0644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:03:14 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:03:14 3: TUL EIB refused message: 9c11162206e300800644
2014.01.25 15:04:47 2: EIB EIB_4200 060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:04:47 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:04:47 3: TUL EIB refused message: 9c11112200e30080060f
2014.01.25 15:05:52 2: EIB EIB_4101 15
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:05:52 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:05:52 3: TUL EIB refused message: 9c110e2101e2008015
2014.01.25 15:06:23 2: EIB EIB_4202 0c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:23 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:23 3: TUL EIB refused message: 9c11172202e300800c40
2014.01.25 15:06:33 2: EIB EIB_4203 ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:06:33 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:06:33 3: TUL EIB refused message: 9c11172203e20080ff
2014.01.25 15:07:35 2: EIB EIB_4109 ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:07:35 3: Control Byte 0x9c does not match expected mask 0xB0
2014.01.25 15:07:35 3: TUL EIB refused message: 9c11092109e20080ff
2014.01.25 15:08:37 2: EIB EIB_4207 ff
einfach aufhören. Eine richtige Absturz- oder Fehlermeldung gibt es leider nicht.

Herr Tostmann, vom Ingenieurbüro Tostmann und Inhaber von busware.de, verweist für die Lösung des Problems auf die FHEM Community.

Könnt ihr mir bitte helfen, die Fehlerursache zu identifizieren/zu finden und das Problem zu lösen?

Vielen Dank für eure Hilfe und Unterstützung!

Grüße
Neh Coy

Moin,
mit EIB kenn ich mich nicht aus - es wird doch aber oft von seltsamen Effekten beim RPi bercihtet, wenn dessen Stromversorgung über den Standard-Mini-USB erfolgt, da dann nur 500mA für RPi incl aller angeschlossenen Geräte zur Verfügung stehen.
Kannst Du das ausschließen? Hast Du mal Stromversorgung über die regulären USB-Anschlüsse versucht?
Gruß, Uli

Hallo UliM!

Danke für den Hinweis, aber ich wage es, die Spannungsversorgung auszuschließen.
Der Raspberry wird über ein eigens für ihn angeschafftes Netzteil versorgt:
http://www.amazon.de/Steckernetzteil-Micro-USB-1200mA-Raspberry-Pi/dp/B008XI52BS

Kann man irgendwie, irgendwo auslesen, warum/wo FHEM hängen bleibt?

Gruß
NehCoy

Wenn FHEM sich auf dem Raspi aufhänhgt, wie sieht es mit der uptime aus?

Mich wundert, das fhem "weg" sein soll, aber der Rapsi noch läuft.

P.S: wenn fhem "weg" ist, was sagt, per ssh, ein "ps aux | grep fhem"?

Nun bin ich völlig perplex!  :-[
Als ich gestern Abend nachschauen wollte läuft der Raspberry und FHEM, als ob es nie Probleme gegeben hätte.
Mir ist aber aufgefallen, dass inzwischen 11 neue KNX Devices gefunden wurden.
Wo die auch immer her kamen. Habe die Unterlagen mit den ganzen Adressen vom Elektriker noch nicht bekommen.
Habe jetzt auch für diese neuen Geräte die Logfiles deaktiviert. Bin mal gespannt, wie das weiter geht.

Ich beobachte weiter und melde mich wieder.

Danke.

Hallo,

wenn du den TUL direkt im Raspi stecken hast, würde ich empfehlen, einen aktives (!) USB-Hub dazwischen zu klemmen. Der Raspi hat nicht genügend Reserven um stromhungrige USB-Geräte zu versorgen. Das führt dann manchmal zu seltsamen Effekten.

Gruß
Carsten

Also ich kann nur empfehlen die Stromversorgung genau unter die Lupe zu nehmen. Ich hatte vor kurzem auch jede Menge Fehler in fhem, die letztendlich am netzteil lagen, war auch ein simples 6€ Teil mit 1,2Ampere. Hier hat mir dann einer den Tipp gegeben ein phihong Netzteil zu kaufen, ist zwar Teuer erspart aber ne Menge ärger und 2-3 billig Netzteile sind auch so teuer. Ich hab mir jetzt das hier bestellt:
http://www.reichelt.de/PSC-12R-050/3/index.html?&ACTION=3&LA=446&ARTICLE=111197
jetzt such ich noch nach einem Adapter von hohlstecker-buchse auf micro-usb. ansonsten, muss ich was basteln.

@ strauch

Wenn möglich, den Pi nicht über den micro-USB Port speisen!
http://www.forum-raspberrypi.de/Thread-info-stromversorgung-raspberry-pi
entweder über den normalen USB-Port oder über die GPIO-Pinleiste.

@ all
bevor man sich irgendwelche neuen Netzteile kauft, kann man auch aus einem vorhandenen PC (Netzteil) die 5V abzweigen.
Wenn der Pi dann stabil rennt, dann Vernünftiges Netzteil für den Pi kaufen.

Gruß Joachim

@joachim, danke für den Tipp, dann werde ich einfach noch eine Buchse bestellen, ein Loch ins Raspberrygehäuse bohren und das mit Kabeln auf die Pfostenstecker packen: http://www.reichelt.de/HEBL-21/3/index.html?&ACTION=3&LA=446&ARTICLE=8524

Ihr habt also das Netzteil in Verdacht, das ich verwende:
http://www.amazon.de/Steckernetzteil-Micro-USB-1200mA-Raspberry-Pi/dp/B008XI52BS !?  ???

Verwunderlich ist, dass es zu sporadischen Fehlern kommt erst nach etlichen Stunden kommt - und in den letzten 24 Stunden gar nicht.
Und das der Pi von der instabilen Stromversorgung selbst nicht betroffen ist.
Ich würde da nämlich dann einen Reset erwarten, der auch dazu führt, dass dann FHEM neu gestartet wird und somit wieder ansprechbar ist. Es stürzt(e) ja aber nur FHEM ab, oder hängte sich auf.
Letzteres könnte wiederum von einer instabilen Spannung daher rühren, dass das TPUART USB Modul in einen ungültigen Zustand kommt und FHEM dann in irgendeiner Leseschleife hängen bleibt.

Dann könnte man so was aber versuchen in einer zukünftigen Version von FHEM softwareseitig abzufangen und das TPUART USB Modul neu starten/initialisieren...

Oder denke ich jetzt da so falsch?

Gruß
NehCoy

NehCoy,
lese Dir den Link von mir durch, da werden die Probleme, die auftreten können eigentlich sehr anschaulich erklärt.
Der Pi selbst braucht nur 3,3V, die er intern mit einem StepDown Wandler herstellt, der USB-Hub, an dem auch das Lan hängt braucht 5V.
Wenn hier Instabilitäten auftreten kommt es zu mekwürdigen Phänomenen.
Wenn Du mir das nicht glaubst, mach weiter wie bisher.

Gruß Joachim

Also ich hatte folgende Symptome die mit einem neuen Netzteil verschwunden sind:

Empfangsprobleme mit meinem CUL für Homematic.
Absturz nach speichern der fhem.cfg
Irgendeine Änderung vorgenommen und danach nicht mehr ansprechbar.
Manchmal wurden Dinge nicht richtig geschaltet oder nicht darauf reagiert (notify)

Zum Schluss dann ganz extrem:
Keine Bildschirmausgabe aber ansprechbar per LAN
Bildschirmausgabe aber nicht mehr ansprechbar per LAN
Dateisystem mit Fehlern so das der Raspberry nicht mehr durchstartete

Hallo Jaochim,

deinen Link habe ich durchgelesen.

Dennoch stellt sich mir die Frage, ob ein -durch einen Spannungseinbruch verursachter- unzulässiger Zustand des TPUART USB Moduls dazu führt, das FHEM hängen bleibt und ob so ein Fall/Zustand durch eine Anpassung der Firmware erkannt werden und durch einen Neustart des USB Moduls behoben werden kann.

Gruß
NehCoy

Aus eigener Erfahrung:
Ja, FHEM bleibt hängen, sogar soweit, dass sämtliche Standartmöglichkeiten von Linux, einen Prozess zu killen, nicht mehr greifen! Interessanterweise läuft eventuell der Pi ansonsten sauber weiter, wie von Strauch schon geschrieben wurde.
Ob man FHEM dahingehend anpassen kann? Natürlich, ist aber nach meinem dafürhalten den Aufwand nicht wert. Außerdem ist es nicht das Problem von FHEM, wenn es auf einem instabilen System läuft, dann müssen die Ursachen und nicht die Symptome beseitigt werden.

Gruß Joachim

ZitatJa, FHEM bleibt hängen, sogar soweit, dass sämtliche Standartmöglichkeiten von Linux, einen Prozess zu killen, nicht mehr greifen! Interessanterweise läuft eventuell der Pi ansonsten sauber weiter, wie von Strauch schon geschrieben wurde.

Was ja auch genau meine Erfahrung ist.

ZitatOb man FHEM dahingehend anpassen kann? Natürlich, ist aber nach meinem dafürhalten den Aufwand nicht wert. Außerdem ist es nicht das Problem von FHEM, wenn es auf einem instabilen System läuft, dann müssen die Ursachen und nicht die Symptome beseitigt werden.

Jain. Zwar mag jetzt die Spannungsversorgung die Ursache für das Aufhängen des TPUART USB Moduls und FHEM sein, aber war sagt, dass nicht ein anderes Ereignis ebenfalls dazu führt. Es ist doch noch nur gut, wenn FHEM so stabil läuft, dass es solche "Probleme" erkennt, meldet, protokolliert und "Gegenmaßnahmen" ergreift.
Zumindest sehe ich das so.

Und wie habt Ihr dann versucht, FHEM zu killen? Mit einem "normalen" kill, oder mit "kill -9"?

Wenn ein "normales" kill nicht funktioniert, ist es noch nicht sooo gravierend. Wenn ein -9 nicht funktioniert, dagegen ...

Ich habe den kompletten Raspberry neugestartet:
sudo reboot

ZitatJain. Zwar mag jetzt die Spannungsversorgung die Ursache für das Aufhängen des TPUART USB Moduls und FHEM sein, aber war sagt, dass nicht ein anderes Ereignis ebenfalls dazu führt. Es ist doch noch nur gut, wenn FHEM so stabil läuft, dass es solche "Probleme" erkennt, meldet, protokolliert und "Gegenmaßnahmen" ergreift.
Zumindest sehe ich das so.

Wenn Du das so siehst, dann programmiere die entsprechenden Überwachungsmaßnahmen, und stelle sie der Allgemeinheit zur verfügung.

@ Wernieman,
Bei mir war FHEM im Status "D", und damit hat auch ein kill -9 nicht geholfen.

Gruß Joachim

Hallo,

ZitatZwar mag jetzt die Spannungsversorgung die Ursache für das Aufhängen des TPUART USB Moduls und FHEM sein, aber war sagt, dass nicht ein anderes Ereignis ebenfalls dazu führt.

Dann sollte man doch bei den einfacheren Dingen anfangen und nicht gleich "Überwachungs- und Protokollierungsprogramme" erstellen.
Spannungsversorgung tauschen und einen aktiven USB-Hub dran und schauen was passiert.

Fehler weg?
Arbeit erledigt.

Fehler noch da?
Ok - weiter suchen was los ist/sein kann.

Grüße

ZitatWenn Du das so siehst, dann programmiere die entsprechenden Überwachungsmaßnahmen, und stelle sie der Allgemeinheit zur verfügung.

Wenn mein Know-how soweit ist, gerne.
Ich muss allerdings erst mal anfangen Perl zu erlernen. Bis ich dann dazu kommen würde mich um solche Routinen zu kümmern vergeht also ein Weile.

ZitatSpannungsversorgung tauschen und einen aktiven USB-Hub dran und schauen was passiert.

Du meinst di Variante zwei von dem Artikel, den Joachim gepostet hat!?!
ttp://www.forum-raspberrypi.de/Thread-info-stromversorgung-raspberry-pi
Dazu muss ich erst mal "Shoppen" gehen...


Übrigens: Inzwischen ist das Fehlerbild wieder aufgetreten:
Der Befehl "ps aux | grep fhem" liefert folgendes Ergebnis:

pi@raspberrypi ~ $ ps aux | grep fhem
root      2562  0.0  0.1   1692   548 ?        Ss   08:13   0:07 startpar -f -- fhem
fhem      2747 90.5  2.6  14368 11868 ?        R    17:05 193:35 /usr/bin/perl fhem.pl fhem.cfg
pi        2832  0.0  0.1   3544   808 pts/2    S+   20:39   0:00 grep --color=auto fhem

Bevor unnötig Geld ausgegeben wird!

Zitat@ all
bevor man sich irgendwelche neuen Netzteile kauft, kann man auch aus einem vorhandenen PC (Netzteil) die 5V abzweigen.
Wenn der Pi dann stabil rennt, dann Vernünftiges Netzteil für den Pi kaufen.

Laut dem Listing "verbrät" fhem bein Dir 90.5% CPU time ... kannst Du mal gucken, ober die CPU überhaupt noch "Luft" hat?

Danke für eure Antworten!  :)

Zitat von: Joachim am 29 Januar 2014, 20:50:17
Bevor unnötig Geld ausgegeben wird!

Den Tipp hatte ich bereits gelesen. Aber ich habe nicht einfach so ein PC-Netzteil rumliegen.
Zudem wäre der Gesamtwirkungsgrad recht bescheiden.
Und -last but not least- sieht das im Wandschrank recht unschön aus! ;)

Zitat von: Wernieman am 29 Januar 2014, 21:06:52
Laut dem Listing "verbrät" fhem bein Dir 90.5% CPU time ... kannst Du mal gucken, ober die CPU überhaupt noch "Luft" hat?

Meinst du mit "Luft" freie Rechenkapazität, oder "Luft" bzgl. Überhitzung und Drosselung?
Letzteres glaube ich nicht, dass es ein Problem sein könnte.
Ersteres muss ich mal nach dem Linux-Befehl schauen, der mir die Gesamtresiurcenauslastung auflistet.
Wobei über 90% für mich irgendwie nach "aufhängen" und "Endlosschleife" riecht...

Hinweis:
Einfach mal "top" verwenden .... ich meinte die CPU-Auslastung

Edit:
oder das im Forum erweiterte SYSMON-Modul verwenden ...

ZitatEinfach mal "top" verwenden .... ich meinte die CPU-Auslastung

Also wenn sich FHEM nicht aufgehängt hat, liegt die durchschnittliche CPU-Last zwischen 1,5 und 2 %.
Somit sind über 98% Idle Time.

Der Befehl "ps aux | grep fhem" liefert mir eine CPU-Last von 0,1%.

Zitatoder das im Forum erweiterte SYSMON-Modul verwenden ...

Danke. Werde mich mal umschauen.

Interessant währe dann dagegen, wenn er sich "Aufhängt". Wenn dann in Summe die CPU-Last bei 100% ...

Zitatdas im Forum erweiterte SYSMON-Modul verwenden ...

Meinst du das hier:
http://forum.fhem.de/index.php?topic=17201.0
:o
Wobei ich mich frage, was das helfen soll, da doch anscheinend die Darstellung über das Webfrontend erfolgt. Und das ist ja bekanntlich nicht mehr erreichbar.

ZitatInteressant währe dann dagegen, wenn er sich "Aufhängt". Wenn dann in Summe die CPU-Last bei 100% ...

War mir klar. ;) Liefere ich dann beim nächsten "Absturz" nach ...  ;D

Et voilà, hier sind die Ergebnisse.

pi@raspberrypi ~ $ ps aux | grep fhem
root 1750 0.0 0.1 1756 532 ? S Jan29 0:00 /bin/sh /etc/init.d/fhem start
fhem 1755 2.6 2.7 14616 12264 ? R Jan29 18:36 perl fhem.pl fhem.cfg
pi 2319 0.0 0.1 3548 864 pts/2 S+ 08:14 0:00 grep --color=auto fhem


Das Ergebnis von "top" als Screenshot als Analge zu diesem Beitrag.
Merkwürdig, dass über "top" eine CPU-Last von über 98% für FHEM angezeigt wird, aber über ps jetzt nur 2,6%.

SYSMON Protokolliert auch die Werte in einem Logfile, d.h. sie sind auch für die Vergangenheit einsehbar.

Wenn top und ps unterschiedliche Werte anzeige, könnte es daran liegen, das ps nur einen "Ist-Stand" zeigt, während top die letzten 5? sec? verwendet. Da praktisch nur fhem arbeitet und sonst nichts anderes (abgesehen von System mit 7,2%)

Er hängt nicht beim lesen/schreiben (da z.B. waiting = 0), hat aber auch keine Reserven mehr (idle=0) ... und Du kannst fhem wirklich nicht mehr beenden? auch mit "kill -9" nicht?

Zurück zur Spannungsversorgung:
Das Hauptproblem beider Versorgung über die Micro-USB Buchse ist doch die 1A-Sicherung.
Warum überbrückt man die nicht einfach. Dann kommt man schlussendlich beim gleichen raus, als würde man die normalen USB-A Ports verwenden...

Zitat... und Du kannst fhem wirklich nicht mehr beenden? auch mit "kill -9" nicht?

Kann ich nicht sagen, da noch nie getestet.
Soll ich dann lieber "kill -9 <id>" oder "killall -9 fhem" verwenden?

killall hat den Vorteil, alle fhem.pl zu killen. killall hat den Nachteil, alle Prozesse mit "namen" fhem.pl zu killen .... mußt Du selber Kosten/Risiken ermitteln

Dann warten wir mal, den nächsten Absturz ab...

Da ist er auch schon wieder.
Angefügt die Screenshots des Befehls "top" bevor und nachdem der Befehl "sudo kill -9 >id>" ausgeführt wurde.
Die Konsolen Ein- und Ausgaben sahen dann so aus:
pi@raspberrypi ~ $ ps aux | grep fhem
root      1765  0.0  0.1   1756   532 ?        S    13:43   0:00 /bin/sh /etc/init.d/fhem start
fhem      1768 31.1  3.0  16068 13728 ?        R    13:43  96:53 perl fhem.pl fhem.cfg
pi        3811  0.0  0.1   3548   864 pts/0    S+   18:54   0:00 grep --color=auto fhem
pi@raspberrypi ~ $ kill -9 1768
-bash: kill: (1768) - Operation not permitted
pi@raspberrypi ~ $ sudo kill -9 1768
pi@raspberrypi ~ $ ps aux | grep fhem
pi        3831  1.0  0.1   3544   808 pts/0    S+   18:55   0:00 grep --color=auto fhem
pi@raspberrypi ~ $

Ebenfalls angefügt: Ein Screenshot von der grafischen SYSMON-Ausgabe.

Jetzt würde mich noch die CPU system/idle etc Werte im Grafen interessieren ....

Scheinbar "dreht" bei Dir fhem durch. Das System an sich selber scheint zu funktionieren, sonst würde ein "kill -9" nicht funktionieren. Ein Neustart des fhem war O.K.?

Kannst Du gucken, ob um 17:10 was besonderes im log war? ~10 Minuten vorher/nachher?

Der regulären Log ist von mir deaktiviert worden, um diesen als Fehlerquelle auszuschließen.
Aber bis dahin war bis auf das bereits gepostete (http://forum.fhem.de/index.php/topic,19376.msg130112.html#msg130112) nicht außergewöhnliches drin.
Hätte höchstens noch die sysmon-Logdatei im Angebot.

FHEM hat sich mal aufgehängt.
Kill -9 war wieder möglich.
Dieses mal habe ich versucht FHEM manuell zu starten:
pi@raspberrypi /opt/fhem $ Can't open ./log/fhem-2014-01.log: Permission denied at fhem.pl line 1960, <$fh> line 10.

pi@raspberrypi /opt/fhem $ sudo perl fhem.pl fhem.cfg
pi@raspberrypi /opt/fhem $ defined(@array) is deprecated at ./FHEM/00_TUL.pm
line 704, <$fh> line 37.
(Maybe you should just omit the defined()?)

Auf der Webfrontend FHEM konnte ich danach wieder zugreifen.
Ob ich auch auf den KNX-Bus zugreifen und Lampen ein- und ausschalten kann, kann ich im Moment nicht testen, da ich Remote auf Verbunden bin.

Ein Auszug aus dem inzwischen weider aktivierten Logfile und die Diagramme von SYSMON sind diesem Beitrag angefügt.

Mhhh ... man sieht eigentlich nur, das kurz vor 8:00 Dein System sich verabschiedet hat. Deshalb ist die Kurve von 8:00 bis jetzt so gerade. Kannst Du auch die CPUWerte in die Grafen bekommen? Also nicht nur die Termperatur? Dann würden wir sehen, ob VOR dem Absturz die CPU schon zu tun  hatte und in welchem "Bereich" ..

Hallo Wernieman,

danke für deine Antwort!

ZitatKannst Du auch die CPUWerte in die Grafen bekommen?

Ich schau mal, was in der Doku zu SYSMON steht ...

ZitatOb ich auch auf den KNX-Bus zugreifen und Lampen ein- und ausschalten kann, kann ich im Moment nicht testen, da ich Remote auf Verbunden bin.

Ich glaube nicht, dass ich es hätte können.
Im Status des Webfrontends war folgendes angezeigt:
TUL
EIB   disconnected

Nach einem Systemneustart mit "sudo reboot" steht da nun:
TUL
EIB   Initialized

Damit wird diese Fehlermeldung doch irgendeinen Grund gehabt haben.
pi@raspberrypi /opt/fhem $ defined(@array) is deprecated at ./FHEM/00_TUL.pm
line 704, <$fh> line 37.

Gruß
NehCoy

"deprecated" bedeutet eigentlich, das es in Perl als veraltet gilt und in Zukunft aus Perl entfernt wird. Ist also eher eine Warnung als ein Fehler

Hast Du vor 8:00 etwas besonderes im Logfile? Ansonsten mal "verbose 5" setzen

Also ich sehe in dem Beitrag angehängten Logfile (http://forum.fhem.de/index.php?action=dlattach;topic=19376.0;attach=11519) nichts besonderes.
"verbose" habe ich jetzt mal auf "5" gesetzt.


Edit:
Ähm ... Die "Load" wird doch angezeigt (http://forum.fhem.de/index.php?action=dlattach;topic=19376.0;attach=11520;image).
Der mittlere Graph. Steigt ab gegen 7:30 Uhr linear an...

Die Load und die CPU Usage sind aber Unterschiedliche Sachen. Eine load von 1 bedeutet, das 1 Prozess auf io-Wartet. Ich habe schon Server mit einer Load von 10.000 gesehen, wo sich die CPU gelangweilt hat (O.K. das ist schon ein faild). Auche eine load von 1, die CPU dreht aber durch ist auch schon vorgekommen.

Kurzgefasst:
load ist ein Hinweis, aber keine "echte" Auslastungsanzeige

Ich hab schonmal gefragt, aber keine Antwort gesehen.
Hast du den TUL direkt im Raspi? Wenn ja, häng ihn ( und alle anderen USB-Geräte ) mal an ein aktives (!) USB-Hub.

Ich hatte ein ähnliches Verhalten bei einem UMTS-Stick, den ich zum Testen auch direkt im Raspi hatte. Prinzipiell funktionierte alles, aber unter bestimmten Bedingungen ( ich nehme an, schlechtes Netz ) brauchte er mehr Strom und der Raspi fing an zu Mucken.

Meine Vermutung ist, dass der Stick nicht genug Strom bekommt, abschmiert und FHEM durchdreht, weil er nicht mehr ( richtig ) erreichbar ist.

Edit: Ich meine übrigens nicht, dass du den Raspi über den Hub speisen sollst, sondern nur die angehängten USB-Geräte. Ersteres steht dir natürlich auch frei, prinzipiell sollte sich das Problem aber schon lösen, wenn der Raspi die USB-Peripherie nicht mehr selbst versorgen muss, sofern du nichts an den GPIOs angeschlossen hast.

Hi Carsten,

falls du das gefragt hast und ich darauf nicht geantwortet habe, tut mir das leid.
Nein, dass ist noch nicht der Fall. Steht aber auf meiner ToDo-Liste.
Nur die Hubs, die ich daheim rumfahren habe, haben leider kein eigenes Netzteil! :(

Naja, die kosten ja nicht die Welt und man kriegt sie überall. Hab mir letztens noch welche für 5€ aus dem Tchibo-Rabattregal gekauft :)

Hallo!

Ich habe jetzt mal einen aktiven Hub bestellt. Komme nicht dazu einen kaufen zu gehen.
Dabei habe ich auch darauf geachtet, dass das Netzteil "genug" Power hat.
Habe aktive 7-Port Hubs gefunden, deren Netzteil nur 2A liefert.  :o

Zur Fehlermeldung (Logfile mit verbose 5): Da steht was besonderes
2014.02.03 08:23:28 5: waiting to receive 8 bytes ...
2014.02.03 08:23:28 5: Received fixlen packet: bc11

2014.02.03 08:23:28 5: Received fixlen packet: 0919

2014.02.03 08:23:28 5: Received fixlen packet: 00e1

2014.02.03 08:23:28 5: Received fixlen packet: 00

2014.02.03 08:23:28 5: Received fixlen packet: 80

2014.02.03 08:23:28 5: getRequest len: 8 packet: bc11091900e10080

2014.02.03 08:23:28 5: receiving telegram with len: 9
2014.02.03 08:23:28 5: waiting to receive 1 bytes ...
2014.02.03 08:23:28 5: Received fixlen packet: 23

2014.02.03 08:23:28 5: getRequest len: 1 packet: 23

2014.02.03 08:23:28 5: receiving telegram with len: 9
2014.02.03 08:23:28 5: Telegram: (8): bc11091900e10080
2014.02.03 08:23:28 5: Buf: (0):
2014.02.03 08:23:28 5: msg cmd: 0x80 datalen: 2
2014.02.03 08:23:28 5: msg cmd: 0x80 datalen: 2 apci: 2
2014.02.03 08:23:28 5: decode_tpuart byte len: 1 array size: 1
2014.02.03 08:23:28 5: SimpleRead msg.type: write, msg.src: 1109, msg.dst: 3100
2014.02.03 08:23:28 5: SimpleRead data: 00
2014.02.03 08:23:28 4: SimpleRead: B1109w310000

2014.02.03 08:23:28 4: EIB: B1109w310000
2014.02.03 08:23:28 5: EIB dispatch B1109w310000
2014.02.03 08:23:28 2: EIB EIB_3100 off
2014.02.03 08:23:28 5: Triggering EIB_3100 (1 changes)
2014.02.03 08:23:28 5: Notify loop for EIB_3100 off
2014.02.03 08:23:28 4: eventTypes: EIB EIB_3100 off -> off
2014.02.03 08:23:29 5: waiting to receive 8 bytes ...
2014.02.03 08:23:29 5: Received fixlen packet: bc11

2014.02.03 08:23:29 5: Received fixlen packet: 0919

2014.02.03 08:23:29 5: Received fixlen packet: 00

2014.02.03 08:23:29 5: Received fixlen packet: e100

2014.02.03 08:23:29 5: Received fixlen packet: 80

2014.02.03 08:23:29 5: getRequest len: 8 packet: bc11091900e10080

2014.02.03 08:23:29 5: receiving telegram with len: 9
2014.02.03 08:23:29 5: waiting to receive 1 bytes ...
2014.02.03 08:23:29 5: Received fixlen packet: 23

2014.02.03 08:23:29 5: getRequest len: 1 packet: 23

2014.02.03 08:23:29 5: receiving telegram with len: 9
2014.02.03 08:23:29 5: Telegram: (8): bc11091900e10080
2014.02.03 08:23:29 5: Buf: (0):
2014.02.03 08:23:29 5: msg cmd: 0x80 datalen: 2
2014.02.03 08:23:29 5: msg cmd: 0x80 datalen: 2 apci: 2
2014.02.03 08:23:29 5: decode_tpuart byte len: 1 array size: 1
2014.02.03 08:23:29 5: SimpleRead msg.type: write, msg.src: 1109, msg.dst: 3100
2014.02.03 08:23:29 5: SimpleRead data: 00
2014.02.03 08:23:29 4: SimpleRead: B1109w310000

2014.02.03 08:23:29 4: EIB: B1109w310000
2014.02.03 08:23:29 5: EIB dispatch B1109w310000
2014.02.03 08:23:29 2: EIB EIB_3100 off
2014.02.03 08:23:29 5: Triggering EIB_3100 (1 changes)
2014.02.03 08:23:29 5: Notify loop for EIB_3100 off
2014.02.03 [b]08:23:29[/b] 4: eventTypes: EIB EIB_3100 off -> off
[b]2014.02.03 08:23:29 5: waiting to receive 8 bytes ...[/b]
2014.02.03 [b]19:50:28[/b] 1: Including fhem.cfg

Gruß
NehCoy

Edit:
Das warten auf Bytes war auch der letzte Eintrag vom letzten aufhängen heute Nacht:
2014.02.04 06:02:28 4: eventTypes: SYSMON sysmon ram: Total: 437.68 MB, Used: 29.75 MB, 6.80 %, Free: 407.93 MB -> ram: Total: .* MB, Used: .* MB, .* %, Free: .* MB
2014.02.04 06:02:40 5: waiting to receive 8 bytes ...
2014.02.04 06:02:40 5: Received fixlen packet: bc11
2014.02.04 06:02:40 5: Received fixlen packet: 0f11
2014.02.04 06:02:40 5: Received fixlen packet: 0f
2014.02.04 06:02:40 5: Received fixlen packet: e100
2014.02.04 06:02:40 5: Received fixlen packet: 80
2014.02.04 06:02:40 5: getRequest len: 8 packet: bc110f110fe10080
2014.02.04 06:02:40 5: receiving telegram with len: 9
2014.02.04 06:02:40 5: waiting to receive 1 bytes ...
2014.02.04 06:02:40 5: Received fixlen packet: 22
2014.02.04 06:02:40 5: getRequest len: 1 packet: 22
2014.02.04 06:02:40 5: receiving telegram with len: 9
2014.02.04 06:02:40 5: Telegram: (8): bc110f110fe10080
2014.02.04 06:02:40 5: Buf: (0):
2014.02.04 06:02:40 5: msg cmd: 0x80 datalen: 2
2014.02.04 06:02:40 5: msg cmd: 0x80 datalen: 2 apci: 2
2014.02.04 06:02:40 5: decode_tpuart byte len: 1 array size: 1
2014.02.04 06:02:40 5: SimpleRead msg.type: write, msg.src: 110f, msg.dst: 210f
2014.02.04 06:02:40 5: SimpleRead data: 00
2014.02.04 06:02:40 4: SimpleRead: B110fw210f00
2014.02.04 06:02:40 4: EIB: B110fw210f00
2014.02.04 06:02:40 5: EIB dispatch B110fw210f00
2014.02.04 06:02:40 2: EIB EIB_210f off
2014.02.04 06:02:40 5: Triggering EIB_210f (1 changes)
2014.02.04 06:02:40 5: Notify loop for EIB_210f off
2014.02.04 06:02:40 4: eventTypes: EIB EIB_210f off -> off
2014.02.04 06:02:41 5: waiting to receive 8 bytes ...
2014.02.04 06:02:41 5: Received fixlen packet: bc110e
2014.02.04 06:02:41 5: Received fixlen packet: 19
2014.02.04 06:02:41 5: Received fixlen packet: 0ce1
2014.02.04 06:02:41 5: Received fixlen packet: 00
2014.02.04 06:02:41 5: Received fixlen packet: 80
2014.02.04 06:02:41 5: getRequest len: 8 packet: bc110e190ce10080
2014.02.04 06:02:41 5: receiving telegram with len: 9
2014.02.04 06:02:41 5: waiting to receive 1 bytes ...
2014.02.04 06:02:41 5: Received fixlen packet: 28
2014.02.04 06:02:41 5: getRequest len: 1 packet: 28
2014.02.04 06:02:41 5: receiving telegram with len: 9
2014.02.04 06:02:41 5: Telegram: (8): bc110e190ce10080
2014.02.04 06:02:41 5: Buf: (0):
2014.02.04 06:02:41 5: msg cmd: 0x80 datalen: 2
2014.02.04 06:02:41 5: msg cmd: 0x80 datalen: 2 apci: 2
2014.02.04 06:02:41 5: decode_tpuart byte len: 1 array size: 1
2014.02.04 06:02:41 5: SimpleRead msg.type: write, msg.src: 110e, msg.dst: 310c
2014.02.04 06:02:41 5: SimpleRead data: 00
2014.02.04 06:02:41 4: SimpleRead: B110ew310c00
2014.02.04 06:02:41 4: EIB: B110ew310c00
2014.02.04 06:02:41 5: EIB dispatch B110ew310c00
2014.02.04 06:02:41 2: EIB EIB_310c off
2014.02.04 06:02:41 5: Triggering EIB_310c (1 changes)
2014.02.04 06:02:41 5: Notify loop for EIB_310c off
2014.02.04 06:02:41 4: eventTypes: EIB EIB_310c off -> off
2014.02.04 06:02:41 5: waiting to receive 8 bytes ...
2014.02.04 07:12:32 1: Including fhem.cfg

Wenn ich das hier aber richtig verstehe, dann wartet er immer auf die Mindesframelänge von 8 Bytes. Ist das Paket länger, wartet er auf die noch fehlende Anzahl.
Dennoch ist nicht auszuschließen, dass er bei der Kommunikation mit dem TPUART abstürzt/sich aufhängt (die grüne LED des Moduls blinkt ja sehr schnell und schwach).
Bin mal gespannt, ob eine bessere Spannungsversorgung das Problem löst...

Hallo zusammen!

Der aktive Hub wurde heute geliefert! Ergebnis: Schockierend!
Jetzt tritt das Fehlerbild schon nach Sekunden oder wenigen Minuten auf.

Was das ganze noch weiter verschlimmert: Ein reboot des Raspberry Pi bewirkt keinen Reset des Zustands des TUL.
Die grüne LED des TPUART blinkt noch immer schnell und ganz schwach vor sich hin.
Das liegt vermutlich daran, dass der Reset des USB-Interfaces nur die Kommunikation mit dem USB-Hub (Chip) betrifft und nicht die des KNX USB-Adapters!  :(

Der Pi wird weiterhin über ein sperates Netzteil mit Spannung versorgt. Für den Stick und den RaspPi muss also jetzt mehr als genug energie zur Verfügung stehen!

Bin hier echt am verzweifeln!  :'(

Habt ihr weitere Ideen, woran das liegen könnte und wie man dem Problem entgegenwirken kann?

Viele Grüße
NehCoy

Edit:
Im Moment läuft es eine Stunde ...


Edit 2:
10min später. Ein paar Lampen an und ausgeschaltet und vorbei.
System hat sich schon wieder aufgehängt!  :'(

Edit 3:
Ein "sudo reboot" bewirk wohl doch, dass wieder eine Verbindung aufgebaut werden kann.
Weiß nicht, was da vorhin war ...

Gehen euch auch die Ideen aus?  ???


Edit:
Habe eben gelesen, dass die default-Baudrate 19200 ist. Bei mir stand sie auf 57600.  :o
Die Baudrate ist nun angepasst. Bin mal gespannt ob es hilft.

bevor Du immer neu startest ...

Für die Fehlerübersicht:
Kannst Du nach einem Crash Fhem killen?
Was sagt dmesg, /var/log/messages und /var/log/kern.log?

Da Du "sudo reboot" eingeben konntest, bist Du ja auf den Rechner gekommen und damit lief das System noch. Gewöhne Dir bitte an, bevor Du auf die schnelle "rebootest", Informationen sammeln. Der GROßE Vorteil von Unix (linux) ist, das man meistens noch an Infos kommt und deshalb seltener die "Windows-Lösung" Reboot verwenden muß (sollte)

Hallo Wernieman,

danke, dass du dich wieder meinem Problem annimmst!

ZitatKannst Du nach einem Crash Fhem killen?

Wie schon geschrieben  (http://forum.fhem.de/index.php/topic,19376.msg131578.html#msg131578) ist ein kill -9 möglich.
Jedoch bewirkt, ein manueller Start von FHEM mit "sudo fhem.pl fhem.cfg", dass der TUL nicht initialisiert wird.

Des Weiteren sind mir in der Konsole dann folgende Meldungen aufgefallen:
pi@raspberrypi /opt/fhem $ perl fhem.pl fhem.cfg
Can't open ./log/fhem-2014-02.log: Permission denied at fhem.pl line 1960, <$fh> line 3.
pi@raspberrypi /opt/fhem $ sudo perl fhem.pl fhem.cfg
pi@raspberrypi /opt/fhem $ defined(@array) is deprecated at ./FHEM/00_TUL.pm line 704, <$fh> line 36.
        (Maybe you should just omit the defined()?)
Argument "MB," isn't numeric in addition (+) at (eval 22) line 1, <GEN36> line 1.
Argument "MB," isn't numeric in addition (+) at (eval 23) line 1, <GEN36> line 1.
Argument "%," isn't numeric in addition (+) at (eval 24) line 1, <GEN36> line 1.
Argument "MB," isn't numeric in addition (+) at (eval 25) line 1, <GEN36> line 63.
Argument "MB," isn't numeric in addition (+) at (eval 26) line 1, <GEN36> line 63.
Argument "%," isn't numeric in addition (+) at (eval 27) line 1, <GEN36> line 63.
Argument "MB," isn't numeric in addition (+) at (eval 28) line 1, <GEN36> line 125.
Argument "MB," isn't numeric in addition (+) at (eval 29) line 1, <GEN36> line 125.
Argument "%," isn't numeric in addition (+) at (eval 30) line 1, <GEN36> line 125.
Argument "MB," isn't numeric in addition (+) at (eval 31) line 1, <GEN36> line 187.
Argument "MB," isn't numeric in addition (+) at (eval 32) line 1, <GEN36> line 187.
Argument "%," isn't numeric in addition (+) at (eval 33) line 1, <GEN36> line 187.
Argument "MB," isn't numeric in addition (+) at (eval 34) line 1, <GEN36> line 249.
Argument "MB," isn't numeric in addition (+) at (eval 35) line 1, <GEN36> line 249.
Argument "%," isn't numeric in addition (+) at (eval 36) line 1, <GEN36> line 249.
Argument "MB," isn't numeric in addition (+) at (eval 37) line 1, <GEN36> line 311.
Argument "MB," isn't numeric in addition (+) at (eval 38) line 1, <GEN36> line 311.
Argument "%," isn't numeric in addition (+) at (eval 39) line 1, <GEN36> line 311.
Argument "MB," isn't numeric in addition (+) at (eval 40) line 1, <GEN36> line 373.
Argument "MB," isn't numeric in addition (+) at (eval 41) line 1, <GEN36> line 373.
Argument "%," isn't numeric in addition (+) at (eval 42) line 1, <GEN36> line 373.
Argument "MB," isn't numeric in addition (+) at (eval 43) line 1, <GEN36> line 435.
Argument "MB," isn't numeric in addition (+) at (eval 44) line 1, <GEN36> line 435.
Argument "%," isn't numeric in addition (+) at (eval 45) line 1, <GEN36> line 435.
Argument "MB," isn't numeric in addition (+) at (eval 46) line 1, <GEN36> line 497.
Argument "MB," isn't numeric in addition (+) at (eval 47) line 1, <GEN36> line 497.
Argument "%," isn't numeric in addition (+) at (eval 48) line 1, <GEN36> line 497.
Argument "MB," isn't numeric in addition (+) at (eval 49) line 1, <GEN36> line 559.
Argument "MB," isn't numeric in addition (+) at (eval 50) line 1, <GEN36> line 559.
Argument "%," isn't numeric in addition (+) at (eval 51) line 1, <GEN36> line 559.
Argument "MB," isn't numeric in addition (+) at (eval 52) line 1, <GEN36> line 621.
Argument "MB," isn't numeric in addition (+) at (eval 53) line 1, <GEN36> line 621.
Argument "%," isn't numeric in addition (+) at (eval 54) line 1, <GEN36> line 621.
Argument "MB," isn't numeric in addition (+) at (eval 55) line 1, <GEN36> line 683.
Argument "MB," isn't numeric in addition (+) at (eval 56) line 1, <GEN36> line 683.
Argument "%," isn't numeric in addition (+) at (eval 57) line 1, <GEN36> line 683.
Argument "MB," isn't numeric in addition (+) at (eval 58) line 1, <GEN36> line 745.
Argument "MB," isn't numeric in addition (+) at (eval 59) line 1, <GEN36> line 745.
Argument "%," isn't numeric in addition (+) at (eval 60) line 1, <GEN36> line 745.
Argument "MB," isn't numeric in addition (+) at (eval 61) line 1, <GEN36> line 807.
Argument "MB," isn't numeric in addition (+) at (eval 62) line 1, <GEN36> line 807.
Argument "%," isn't numeric in addition (+) at (eval 63) line 1, <GEN36> line 807.
Argument "MB," isn't numeric in addition (+) at (eval 64) line 1, <GEN36> line 869.
Argument "MB," isn't numeric in addition (+) at (eval 65) line 1, <GEN36> line 869.
Argument "%," isn't numeric in addition (+) at (eval 66) line 1, <GEN36> line 869.
Argument "MB," isn't numeric in addition (+) at (eval 67) line 1, <GEN36> line 931.
Argument "MB," isn't numeric in addition (+) at (eval 68) line 1, <GEN36> line 931.
Argument "%," isn't numeric in addition (+) at (eval 69) line 1, <GEN36> line 931.
Argument "MB," isn't numeric in addition (+) at (eval 70) line 1, <GEN36> line 993.
Argument "MB," isn't numeric in addition (+) at (eval 71) line 1, <GEN36> line 993.
Argument "%," isn't numeric in addition (+) at (eval 72) line 1, <GEN36> line 993.
Argument "MB," isn't numeric in addition (+) at (eval 73) line 1, <GEN36> line 1055.
Argument "MB," isn't numeric in addition (+) at (eval 74) line 1, <GEN36> line 1055.
Argument "%," isn't numeric in addition (+) at (eval 75) line 1, <GEN36> line 1055.
Argument "MB," isn't numeric in addition (+) at (eval 76) line 1, <GEN36> line 1117.
Argument "MB," isn't numeric in addition (+) at (eval 77) line 1, <GEN36> line 1117.
Argument "%," isn't numeric in addition (+) at (eval 78) line 1, <GEN36> line 1117.
Argument "MB," isn't numeric in addition (+) at (eval 79) line 1, <GEN36> line 1179.
Argument "MB," isn't numeric in addition (+) at (eval 80) line 1, <GEN36> line 1179.
Argument "%," isn't numeric in addition (+) at (eval 81) line 1, <GEN36> line 1179.
Argument "MB," isn't numeric in addition (+) at (eval 82) line 1, <GEN36> line 1241.
Argument "MB," isn't numeric in addition (+) at (eval 83) line 1, <GEN36> line 1241.
Argument "%," isn't numeric in addition (+) at (eval 84) line 1, <GEN36> line 1241.
Argument "MB," isn't numeric in addition (+) at (eval 85) line 1, <GEN36> line 1303.
Argument "MB," isn't numeric in addition (+) at (eval 86) line 1, <GEN36> line 1303.
Argument "%," isn't numeric in addition (+) at (eval 87) line 1, <GEN36> line 1303.
Argument "MB," isn't numeric in addition (+) at (eval 88) line 1, <GEN36> line 1365.
Argument "MB," isn't numeric in addition (+) at (eval 89) line 1, <GEN36> line 1365.
Argument "%," isn't numeric in addition (+) at (eval 90) line 1, <GEN36> line 1365.
Argument "MB," isn't numeric in addition (+) at (eval 91) line 1, <GEN36> line 1427.
Argument "MB," isn't numeric in addition (+) at (eval 92) line 1, <GEN36> line 1427.
Argument "%," isn't numeric in addition (+) at (eval 93) line 1, <GEN36> line 1427.
Argument "MB," isn't numeric in addition (+) at (eval 94) line 1, <GEN36> line 1489.
Argument "MB," isn't numeric in addition (+) at (eval 95) line 1, <GEN36> line 1489.
Argument "%," isn't numeric in addition (+) at (eval 96) line 1, <GEN36> line 1489.
Argument "MB," isn't numeric in addition (+) at (eval 97) line 1, <GEN36> line 1551.
Argument "MB," isn't numeric in addition (+) at (eval 98) line 1, <GEN36> line 1551.
Argument "%," isn't numeric in addition (+) at (eval 99) line 1, <GEN36> line 1551.
Argument "MB," isn't numeric in addition (+) at (eval 100) line 1, <GEN36> line 1613.
Argument "MB," isn't numeric in addition (+) at (eval 101) line 1, <GEN36> line 1613.
Argument "%," isn't numeric in addition (+) at (eval 102) line 1, <GEN36> line 1613.
Argument "MB," isn't numeric in addition (+) at (eval 103) line 1, <GEN36> line 1675.
Argument "MB," isn't numeric in addition (+) at (eval 104) line 1, <GEN36> line 1675.
Argument "%," isn't numeric in addition (+) at (eval 105) line 1, <GEN36> line 1675.
Argument "MB," isn't numeric in addition (+) at (eval 106) line 1, <GEN36> line 1737.
Argument "MB," isn't numeric in addition (+) at (eval 107) line 1, <GEN36> line 1737.
Argument "%," isn't numeric in addition (+) at (eval 108) line 1, <GEN36> line 1737.
Argument "MB," isn't numeric in addition (+) at (eval 109) line 1, <GEN36> line 1799.
Argument "MB," isn't numeric in addition (+) at (eval 110) line 1, <GEN36> line 1799.
Argument "%," isn't numeric in addition (+) at (eval 111) line 1, <GEN36> line 1799.
Argument "MB," isn't numeric in addition (+) at (eval 112) line 1, <GEN36> line 1861.
Argument "MB," isn't numeric in addition (+) at (eval 113) line 1, <GEN36> line 1861.
Argument "%," isn't numeric in addition (+) at (eval 114) line 1, <GEN36> line 1861.
Argument "MB," isn't numeric in addition (+) at (eval 115) line 1, <GEN36> line 1923.
Argument "MB," isn't numeric in addition (+) at (eval 116) line 1, <GEN36> line 1923.
Argument "%," isn't numeric in addition (+) at (eval 117) line 1, <GEN36> line 1923.
Argument "MB," isn't numeric in addition (+) at (eval 118) line 1, <GEN36> line 1985.
Argument "MB," isn't numeric in addition (+) at (eval 119) line 1, <GEN36> line 1985.
Argument "%," isn't numeric in addition (+) at (eval 120) line 1, <GEN36> line 1985.
Argument "MB," isn't numeric in addition (+) at (eval 121) line 1, <GEN36> line 2047.
Argument "MB," isn't numeric in addition (+) at (eval 122) line 1, <GEN36> line 2047.
Argument "%," isn't numeric in addition (+) at (eval 123) line 1, <GEN36> line 2047.
Argument "MB," isn't numeric in addition (+) at (eval 124) line 1, <GEN36> line 2109.
Argument "MB," isn't numeric in addition (+) at (eval 125) line 1, <GEN36> line 2109.
Argument "%," isn't numeric in addition (+) at (eval 126) line 1, <GEN36> line 2109.
Argument "MB," isn't numeric in addition (+) at (eval 127) line 1, <GEN36> line 2171.
Argument "MB," isn't numeric in addition (+) at (eval 128) line 1, <GEN36> line 2171.
Argument "%," isn't numeric in addition (+) at (eval 129) line 1, <GEN36> line 2171.
Argument "MB," isn't numeric in addition (+) at (eval 130) line 1, <GEN36> line 2233.
Argument "MB," isn't numeric in addition (+) at (eval 131) line 1, <GEN36> line 2233.
Argument "%," isn't numeric in addition (+) at (eval 132) line 1, <GEN36> line 2233.
Argument "MB," isn't numeric in addition (+) at (eval 133) line 1, <GEN36> line 2295.
Argument "MB," isn't numeric in addition (+) at (eval 134) line 1, <GEN36> line 2295.
Argument "%," isn't numeric in addition (+) at (eval 135) line 1, <GEN36> line 2295.
Argument "MB," isn't numeric in addition (+) at (eval 136) line 1, <GEN36> line 2357.
Argument "MB," isn't numeric in addition (+) at (eval 137) line 1, <GEN36> line 2357.
Argument "%," isn't numeric in addition (+) at (eval 138) line 1, <GEN36> line 2357.
Argument "MB," isn't numeric in addition (+) at (eval 139) line 1, <GEN36> line 2419.
Argument "MB," isn't numeric in addition (+) at (eval 140) line 1, <GEN36> line 2419.
Argument "%," isn't numeric in addition (+) at (eval 141) line 1, <GEN36> line 2419.
Argument "MB," isn't numeric in addition (+) at (eval 142) line 1, <GEN36> line 2481.
Argument "MB," isn't numeric in addition (+) at (eval 143) line 1, <GEN36> line 2481.
Argument "%," isn't numeric in addition (+) at (eval 144) line 1, <GEN36> line 2481.
Argument "MB," isn't numeric in addition (+) at (eval 145) line 1, <GEN36> line 2543.
Argument "MB," isn't numeric in addition (+) at (eval 146) line 1, <GEN36> line 2543.
Argument "%," isn't numeric in addition (+) at (eval 147) line 1, <GEN36> line 2543.
Argument "MB," isn't numeric in addition (+) at (eval 148) line 1, <GEN36> line 2605.
Argument "MB," isn't numeric in addition (+) at (eval 149) line 1, <GEN36> line 2605.
Argument "%," isn't numeric in addition (+) at (eval 150) line 1, <GEN36> line 2605.
Argument "MB," isn't numeric in addition (+) at (eval 151) line 1, <GEN36> line 2667.
Argument "MB," isn't numeric in addition (+) at (eval 152) line 1, <GEN36> line 2667.
Argument "%," isn't numeric in addition (+) at (eval 153) line 1, <GEN36> line 2667.
Argument "MB," isn't numeric in addition (+) at (eval 154) line 1, <GEN36> line 2729.
Argument "MB," isn't numeric in addition (+) at (eval 155) line 1, <GEN36> line 2729.
Argument "%," isn't numeric in addition (+) at (eval 156) line 1, <GEN36> line 2729.
Argument "MB," isn't numeric in addition (+) at (eval 157) line 1, <GEN36> line 2791.
Argument "MB," isn't numeric in addition (+) at (eval 158) line 1, <GEN36> line 2791.
Argument "%," isn't numeric in addition (+) at (eval 159) line 1, <GEN36> line 2791.
Argument "MB," isn't numeric in addition (+) at (eval 160) line 1, <GEN36> line 2841.
Argument "MB," isn't numeric in addition (+) at (eval 161) line 1, <GEN36> line 2841.
Argument "%," isn't numeric in addition (+) at (eval 162) line 1, <GEN36> line 2841.
Argument "MB," isn't numeric in addition (+) at (eval 163) line 1, <GEN36> line 2867.
Argument "MB," isn't numeric in addition (+) at (eval 164) line 1, <GEN36> line 2867.
Argument "%," isn't numeric in addition (+) at (eval 165) line 1, <GEN36> line 2867.
Argument "MB," isn't numeric in addition (+) at (eval 166) line 1, <GEN36> line 2929.
Argument "MB," isn't numeric in addition (+) at (eval 167) line 1, <GEN36> line 2929.
Argument "%," isn't numeric in addition (+) at (eval 168) line 1, <GEN36> line 2929.
Argument "MB," isn't numeric in addition (+) at (eval 169) line 1, <GEN36> line 2991.
Argument "MB," isn't numeric in addition (+) at (eval 170) line 1, <GEN36> line 2991.
Argument "%," isn't numeric in addition (+) at (eval 171) line 1, <GEN36> line 2991.
Argument "MB," isn't numeric in addition (+) at (eval 172) line 1, <GEN36> line 3053.
Argument "MB," isn't numeric in addition (+) at (eval 173) line 1, <GEN36> line 3053.
Argument "%," isn't numeric in addition (+) at (eval 174) line 1, <GEN36> line 3053.
Argument "MB," isn't numeric in addition (+) at (eval 175) line 1, <GEN36> line 3115.
Argument "MB," isn't numeric in addition (+) at (eval 176) line 1, <GEN36> line 3115.
Argument "%," isn't numeric in addition (+) at (eval 177) line 1, <GEN36> line 3115.
Argument "MB," isn't numeric in addition (+) at (eval 178) line 1, <GEN36> line 3177.
Argument "MB," isn't numeric in addition (+) at (eval 179) line 1, <GEN36> line 3177.
Argument "%," isn't numeric in addition (+) at (eval 180) line 1, <GEN36> line 3177.
Argument "MB," isn't numeric in addition (+) at (eval 181) line 1, <GEN36> line 3239.
Argument "MB," isn't numeric in addition (+) at (eval 182) line 1, <GEN36> line 3239.
Argument "%," isn't numeric in addition (+) at (eval 183) line 1, <GEN36> line 3239.
Argument "MB," isn't numeric in addition (+) at (eval 184) line 1, <GEN36> line 3301.
Argument "MB," isn't numeric in addition (+) at (eval 185) line 1, <GEN36> line 3301.
Argument "%," isn't numeric in addition (+) at (eval 186) line 1, <GEN36> line 3301.
Argument "MB," isn't numeric in addition (+) at (eval 187) line 1, <GEN36> line 3363.
Argument "MB," isn't numeric in addition (+) at (eval 188) line 1, <GEN36> line 3363.
Argument "%," isn't numeric in addition (+) at (eval 189) line 1, <GEN36> line 3363.
Argument "MB," isn't numeric in addition (+) at (eval 190) line 1, <GEN36> line 3425.
Argument "MB," isn't numeric in addition (+) at (eval 191) line 1, <GEN36> line 3425.
Argument "%," isn't numeric in addition (+) at (eval 192) line 1, <GEN36> line 3425.
Argument "MB," isn't numeric in addition (+) at (eval 193) line 1, <GEN36> line 3487.
Argument "MB," isn't numeric in addition (+) at (eval 194) line 1, <GEN36> line 3487.
Argument "%," isn't numeric in addition (+) at (eval 195) line 1, <GEN36> line 3487.
Argument "MB," isn't numeric in addition (+) at (eval 196) line 1, <GEN36> line 3549.
Argument "MB," isn't numeric in addition (+) at (eval 197) line 1, <GEN36> line 3549.
Argument "%," isn't numeric in addition (+) at (eval 198) line 1, <GEN36> line 3549.
Argument "MB," isn't numeric in addition (+) at (eval 199) line 1, <GEN36> line 3611.
Argument "MB," isn't numeric in addition (+) at (eval 200) line 1, <GEN36> line 3611.
Argument "%," isn't numeric in addition (+) at (eval 201) line 1, <GEN36> line 3611.
Argument "MB," isn't numeric in addition (+) at (eval 202) line 1, <GEN36> line 3673.
Argument "MB," isn't numeric in addition (+) at (eval 203) line 1, <GEN36> line 3673.
Argument "%," isn't numeric in addition (+) at (eval 204) line 1, <GEN36> line 3673.
Argument "MB," isn't numeric in addition (+) at (eval 205) line 1, <GEN36> line 3735.
Argument "MB," isn't numeric in addition (+) at (eval 206) line 1, <GEN36> line 3735.
Argument "%," isn't numeric in addition (+) at (eval 207) line 1, <GEN36> line 3735.
Argument "MB," isn't numeric in addition (+) at (eval 208) line 1, <GEN36> line 3797.
Argument "MB," isn't numeric in addition (+) at (eval 209) line 1, <GEN36> line 3797.
Argument "%," isn't numeric in addition (+) at (eval 210) line 1, <GEN36> line 3797.
Argument "MB," isn't numeric in addition (+) at (eval 211) line 1, <GEN36> line 3859.
Argument "MB," isn't numeric in addition (+) at (eval 212) line 1, <GEN36> line 3859.
Argument "%," isn't numeric in addition (+) at (eval 213) line 1, <GEN36> line 3859.
Argument "MB," isn't numeric in addition (+) at (eval 214) line 1, <GEN36> line 3921.
Argument "MB," isn't numeric in addition (+) at (eval 215) line 1, <GEN36> line 3921.
Argument "%," isn't numeric in addition (+) at (eval 216) line 1, <GEN36> line 3921.
Argument "MB," isn't numeric in addition (+) at (eval 217) line 1, <GEN36> line 3983.
Argument "MB," isn't numeric in addition (+) at (eval 218) line 1, <GEN36> line 3983.
Argument "%," isn't numeric in addition (+) at (eval 219) line 1, <GEN36> line 3983.
Argument "MB," isn't numeric in addition (+) at (eval 220) line 1, <GEN36> line 4045.
Argument "MB," isn't numeric in addition (+) at (eval 221) line 1, <GEN36> line 4045.
Argument "%," isn't numeric in addition (+) at (eval 222) line 1, <GEN36> line 4045.
Argument "MB," isn't numeric in addition (+) at (eval 223) line 1, <GEN36> line 4107.
Argument "MB," isn't numeric in addition (+) at (eval 224) line 1, <GEN36> line 4107.
Argument "%," isn't numeric in addition (+) at (eval 225) line 1, <GEN36> line 4107.
Argument "MB," isn't numeric in addition (+) at (eval 226) line 1, <GEN36> line 4169.
Argument "MB," isn't numeric in addition (+) at (eval 227) line 1, <GEN36> line 4169.
Argument "%," isn't numeric in addition (+) at (eval 228) line 1, <GEN36> line 4169.
Argument "MB," isn't numeric in addition (+) at (eval 229) line 1, <GEN36> line 4231.
Argument "MB," isn't numeric in addition (+) at (eval 230) line 1, <GEN36> line 4231.
Argument "%," isn't numeric in addition (+) at (eval 231) line 1, <GEN36> line 4231.
Argument "MB," isn't numeric in addition (+) at (eval 232) line 1, <GEN36> line 4293.
Argument "MB," isn't numeric in addition (+) at (eval 233) line 1, <GEN36> line 4293.
Argument "%," isn't numeric in addition (+) at (eval 234) line 1, <GEN36> line 4293.
Argument "MB," isn't numeric in addition (+) at (eval 235) line 1, <GEN36> line 4355.
Argument "MB," isn't numeric in addition (+) at (eval 236) line 1, <GEN36> line 4355.
Argument "%," isn't numeric in addition (+) at (eval 237) line 1, <GEN36> line 4355.
Argument "MB," isn't numeric in addition (+) at (eval 238) line 1, <GEN36> line 4417.
Argument "MB," isn't numeric in addition (+) at (eval 239) line 1, <GEN36> line 4417.
Argument "%," isn't numeric in addition (+) at (eval 240) line 1, <GEN36> line 4417.
Argument "MB," isn't numeric in addition (+) at (eval 241) line 1, <GEN36> line 4479.
Argument "MB," isn't numeric in addition (+) at (eval 242) line 1, <GEN36> line 4479.
Argument "%," isn't numeric in addition (+) at (eval 243) line 1, <GEN36> line 4479.
Argument "MB," isn't numeric in addition (+) at (eval 244) line 1, <GEN36> line 4541.
Argument "MB," isn't numeric in addition (+) at (eval 245) line 1, <GEN36> line 4541.
Argument "%," isn't numeric in addition (+) at (eval 246) line 1, <GEN36> line 4541.
Argument "MB," isn't numeric in addition (+) at (eval 247) line 1, <GEN36> line 4603.
Argument "MB," isn't numeric in addition (+) at (eval 248) line 1, <GEN36> line 4603.
Argument "%," isn't numeric in addition (+) at (eval 249) line 1, <GEN36> line 4603.
Argument "MB," isn't numeric in addition (+) at (eval 250) line 1, <GEN36> line 4623.
Argument "MB," isn't numeric in addition (+) at (eval 251) line 1, <GEN36> line 4623.
Argument "%," isn't numeric in addition (+) at (eval 252) line 1, <GEN36> line 4623.

Zitatbevor Du auf die schnelle "rebootest", Informationen sammeln.

Wie du meinen betagten Versuchen entnehmen kannst, bin ich nicht wirklich firm mit Linux.

Die letzten Einträge

• von dmesg sind:

pi@raspberrypi /var/log $ dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.25+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro    GCC 2012.08) ) #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2708
[    0.000000] cma: CMA: reserved 16 MiB at 1b000000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c05cfd6c, node_mem_map c067d000
[    0.000000]   Normal zone: 896 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 114688 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xd bcm2708.serial=0x   ff7878a4 smsc95xx.macaddr=B8:27:EB:78:78:A4 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dw   c_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 431652k/431652k available, 27100k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05727b4   (5546 kB)
[    0.000000]       .init : 0xc0573000 - 0xc0597424   ( 146 kB)
[    0.000000]       .data : 0xc0598000 - 0xc05d0870   ( 227 kB)
[    0.000000]        .bss : 0xc05d0870 - 0xc067c3e0   ( 687 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:330
[    0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
[    0.000000] Switching to timer-based delay loop
[    0.000000] Console: colour dummy device 80x30
[    0.000000] console [tty1] enabled
[    0.001178] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000)
[    0.001246] pid_max: default: 32768 minimum: 301
[    0.001718] Mount-cache hash table entries: 512
[    0.002521] Initializing cgroup subsys memory
[    0.002632] Initializing cgroup subsys devices
[    0.002674] Initializing cgroup subsys freezer
[    0.002710] Initializing cgroup subsys blkio
[    0.002870] CPU: Testing write buffer coherency: ok
[    0.003350] Setting up static identity map for 0xc0406048 - 0xc04060a4
[    0.005172] devtmpfs: initialized
[    0.019592] NET: Registered protocol family 16
[    0.025539] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[    0.026656] bcm2708.uart_clock = 0
[    0.028381] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[    0.028438] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.028478] mailbox: Broadcom VideoCore Mailbox driver
[    0.028576] bcm2708_vcio: mailbox at f200b880
[    0.028685] bcm_power: Broadcom power driver
[    0.028727] bcm_power_open() -> 0
[    0.028755] bcm_power_request(0, 8)
[    0.529476] bcm_mailbox_read -> 00000080, 0
[    0.529520] bcm_power_request -> 0
[    0.529745] Serial: AMBA PL011 UART driver
[    0.529908] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3
[    0.872038] console [ttyAMA0] enabled
[    0.898008] bio: create slab <bio-0> at 0
[    0.903341] SCSI subsystem initialized
[    0.907316] usbcore: registered new interface driver usbfs
[    0.913034] usbcore: registered new interface driver hub
[    0.918609] usbcore: registered new device driver usb
[    0.925193] Switching to clocksource stc
[    0.929541] FS-Cache: Loaded
[    0.932713] CacheFiles: Loaded
[    0.948512] NET: Registered protocol family 2
[    0.953931] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.961197] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    0.967721] TCP: Hash tables configured (established 4096 bind 4096)
[    0.974193] TCP: reno registered
[    0.977454] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.983364] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.990105] NET: Registered protocol family 1
[    0.995036] RPC: Registered named UNIX socket transport module.
[    1.001098] RPC: Registered udp transport module.
[    1.005824] RPC: Registered tcp transport module.
[    1.010578] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.017924] bcm2708_dma: DMA manager at f2007000
[    1.022742] bcm2708_gpio: bcm2708_gpio_probe c05a5e50
[    1.028195] vc-mem: phys_addr:0x00000000 mem_base=0x1ec00000 mem_size:0x20000000(512 MiB)
[    1.037584] audit: initializing netlink socket (disabled)
[    1.043257] type=2000 audit(0.890:1): initialized
[    1.205023] VFS: Disk quotas dquot_6.5.2
[    1.209427] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.218274] FS-Cache: Netfs 'nfs' registered for caching
[    1.225008] NFS: Registering the id_resolver key type
[    1.230312] Key type id_resolver registered
[    1.234524] Key type id_legacy registered
[    1.239348] msgmni has been set to 875
[    1.245217] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    1.253065] io scheduler noop registered
[    1.257028] io scheduler deadline registered (default)
[    1.262618] io scheduler cfq registered
[    1.266759] bcm2708_fb_debugfs_init: could not create debugfs entry
[    1.274343] BCM2708FB: allocated DMA memory 5b400000
[    1.279497] BCM2708FB: allocated DMA channel 0 @ f2007000
[    1.306360] Console: switching to colour frame buffer device 82x26
[    1.316524] uart-pl011 dev:f1: no DMA platform data
[    1.322936] kgdb: Registered I/O driver kgdboc.
[    1.329559] vc-cma: Videocore CMA driver
[    1.334848] vc-cma: vc_cma_base      = 0x00000000
[    1.340908] vc-cma: vc_cma_size      = 0x00000000 (0 MiB)
[    1.347600] vc-cma: vc_cma_initial   = 0x00000000 (0 MiB)
[    1.363657] brd: module loaded
[    1.373292] loop: module loaded
[    1.377986] vchiq: vchiq_init_state: slot_zero = 0xdb000000, is_master = 0
[    1.387122] Loading iSCSI transport class v2.0-870.
[    1.394558] usbcore: registered new interface driver smsc95xx
[    1.402121] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    1.609410] Core Release: 2.80a
[    1.613823] Setting default values for core params
[    1.619949] Finished setting default values for core params
[    1.826825] Using Buffer DMA mode
[    1.831453] Periodic Transfer Interrupt Enhancement - disabled
[    1.838554] Multiprocessor Interrupt Enhancement - disabled
[    1.845399] OTG VER PARAM: 0, OTG VER FLAG: 0
[    1.851067] Dedicated Tx FIFOs mode
[    1.856368] dwc_otg: Microframe scheduler enabled
[    1.856609] dwc_otg bcm2708_usb: DWC OTG Controller
[    1.862895] dwc_otg bcm2708_usb: new USB bus registered, assigned bus number 1
[    1.871516] dwc_otg bcm2708_usb: irq 32, io mem 0x00000000
[    1.878305] Init: Port Power? op_state=1
[    1.883592] Init: Power Port (0)
[    1.888234] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.896454] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.905092] usb usb1: Product: DWC OTG Controller
[    1.911205] usb usb1: Manufacturer: Linux 3.10.25+ dwc_otg_hcd
[    1.918412] usb usb1: SerialNumber: bcm2708_usb
[    1.925085] hub 1-0:1.0: USB hub found
[    1.930300] hub 1-0:1.0: 1 port detected
[    1.935886] dwc_otg: FIQ enabled
[    1.935902] dwc_otg: NAK holdoff enabled
[    1.935914] dwc_otg: FIQ split fix enabled
[    1.935934] Module dwc_common_port init
[    1.936373] usbcore: registered new interface driver usb-storage
[    1.944178] mousedev: PS/2 mouse device common for all mice
[    1.951824] bcm2835-cpufreq: min=700000 max=700000 cur=700000
[    1.959027] bcm2835-cpufreq: switching to governor powersave
[    1.966089] bcm2835-cpufreq: switching to governor powersave
[    1.973061] cpuidle: using governor ladder
[    1.978373] cpuidle: using governor menu
[    1.983566] sdhci: Secure Digital Host Controller Interface driver
[    1.991033] sdhci: Copyright(c) Pierre Ossman
[    1.996679] sdhci: Enable low-latency mode
[    2.039225] mmc0: SDHCI controller on BCM2708_Arasan [platform] using platform's DMA
[    2.049707] mmc0: BCM2708 SDHC host at 0x20300000 DMA 2 IRQ 77
[    2.056955] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.064108] ledtrig-cpu: registered to indicate activity on CPUs
[    2.073708] hidraw: raw HID events driver (C) Jiri Kosina
[    2.088049] usbcore: registered new interface driver usbhid
[    2.095093] usbhid: USB HID core driver
[    2.104940] TCP: cubic registered
[    2.111688] Initializing XFRM netlink socket
[    2.119405] NET: Registered protocol family 17
[    2.125409] Key type dns_resolver registered
[    2.134374] Indeed it is in host mode hprt0 = 00021501
[    2.141363] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[    2.170006] registered taskstats version 1
[    2.179557] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.199909] Waiting for root device /dev/mmcblk0p2...
[    2.231375] mmc0: read SD Status register (SSR) after 3 attempts
[    2.259247] mmc0: new high speed SDHC card at address aaaa
[    2.269919] mmcblk0: mmc0:aaaa SU08G 7.40 GiB
[    2.277625]  mmcblk0: p1 p2
[    2.326302] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.337504] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    2.346262] devtmpfs: mounted
[    2.351249] Freeing unused kernel memory: 144K (c0573000 - c0597000)
[    2.389288] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.397479] Indeed it is in host mode hprt0 = 00001101
[    2.610051] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[    2.618470] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.629936] hub 1-1:1.0: USB hub found
[    2.635656] hub 1-1:1.0: 3 ports detected
[    2.919665] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    3.030204] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    3.038789] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.062190] smsc95xx v1.0.4
[    3.135410] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:78:78:a4
[    3.229632] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[    3.341357] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608
[    3.359367] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    3.368402] usb 1-1.3: Product: USB2.0 Hub
[    3.389686] hub 1-1.3:1.0: USB hub found
[    3.399444] hub 1-1.3:1.0: 4 ports detected
[    3.689735] usb 1-1.3.1: new high-speed USB device number 5 using dwc_otg
[    3.811298] usb 1-1.3.1: New USB device found, idVendor=05e3, idProduct=0608
[    3.829368] usb 1-1.3.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    3.840584] usb 1-1.3.1: Product: USB2.0 Hub
[    3.858233] hub 1-1.3.1:1.0: USB hub found
[    3.869799] hub 1-1.3.1:1.0: 4 ports detected
[    3.959799] usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg
[    3.987709] udevd[156]: starting version 175
[    4.096436] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
[    4.119376] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[    4.158128] usb 1-1.3.4: Product: TPUART transparent
[    4.178342] usb 1-1.3.4: Manufacturer: busware.de
[    4.189318] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
[    4.508059] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device
[    4.538162] usbcore: registered new interface driver cdc_acm
[    4.579353] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    6.275283] bcm2708-i2s bcm2708-i2s.0: Failed to create debugfs directory
[    9.533287] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    9.992462] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   15.588629] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   18.283392] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   19.792573] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[   26.302600] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
[17253.443757] usb 1-1.3.4: USB disconnect, device number 6
[17314.618210] usb 1-1.3.4: new full-speed USB device number 7 using dwc_otg
[17314.736254] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
[17314.736291] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[17314.736311] usb 1-1.3.4: Product: TPUART transparent
[17314.736328] usb 1-1.3.4: Manufacturer: busware.de
[17314.736344] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
[17314.740795] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device


• Von /var/log/messages sind:

Feb 14 12:45:35 raspberrypi kernel: [   19.792573] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Feb 14 12:45:37 raspberrypi kernel: [   26.302600] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
Feb 14 17:33:01 raspberrypi kernel: [17253.443757] usb 1-1.3.4: USB disconnect, device number 6
Feb 14 17:34:02 raspberrypi kernel: [17314.618210] usb 1-1.3.4: new full-speed USB device number 7 using dwc_otg
Feb 14 17:34:02 raspberrypi kernel: [17314.736254] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 14 17:34:02 raspberrypi kernel: [17314.736291] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 14 17:34:02 raspberrypi kernel: [17314.736311] usb 1-1.3.4: Product: TPUART transparent
Feb 14 17:34:02 raspberrypi kernel: [17314.736328] usb 1-1.3.4: Manufacturer: busware.de
Feb 14 17:34:02 raspberrypi kernel: [17314.736344] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
Feb 14 17:34:02 raspberrypi kernel: [17314.740795] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
~

• und von /var/log/kern.log:

Feb 14 12:45:35 raspberrypi kernel: [    4.508059] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device
Feb 14 12:45:35 raspberrypi kernel: [    4.538162] usbcore: registered new interface driver cdc_acm
Feb 14 12:45:35 raspberrypi kernel: [    4.579353] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Feb 14 12:45:35 raspberrypi kernel: [    6.275283] bcm2708-i2s bcm2708-i2s.0: Failed to create debugfs directory
Feb 14 12:45:35 raspberrypi kernel: [    9.533287] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Feb 14 12:45:35 raspberrypi kernel: [    9.992462] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Feb 14 12:45:35 raspberrypi kernel: [   15.588629] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Feb 14 12:45:35 raspberrypi kernel: [   18.283392] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Feb 14 12:45:35 raspberrypi kernel: [   19.792573] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Feb 14 12:45:37 raspberrypi kernel: [   26.302600] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
Feb 14 17:33:01 raspberrypi kernel: [17253.443757] usb 1-1.3.4: USB disconnect, device number 6
Feb 14 17:34:02 raspberrypi kernel: [17314.618210] usb 1-1.3.4: new full-speed USB device number 7 using dwc_otg
Feb 14 17:34:02 raspberrypi kernel: [17314.736254] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 14 17:34:02 raspberrypi kernel: [17314.736291] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 14 17:34:02 raspberrypi kernel: [17314.736311] usb 1-1.3.4: Product: TPUART transparent
Feb 14 17:34:02 raspberrypi kernel: [17314.736328] usb 1-1.3.4: Manufacturer: busware.de
Feb 14 17:34:02 raspberrypi kernel: [17314.736344] usb 1-1.3.4: SerialNumber: 84038303636<EDIT>
Feb 14 17:34:02 raspberrypi kernel: [17314.740795] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device

Also was ich als Laie da raus lese ist, dass die USB-Verbindung mit dem TUL abbricht. Nur warum?
An der Spannungsversorgung kann es jetzt ja wirklich nicht mehr liegen.
Der TUL ist an einem aktiv versorten Hub angeschlossen.

Hast du einen weiteren Tipp und/oder Empfehlung?

Vielen Dank und viele Grüße
NehCoy

Ich hatte mal mit einem ähnlichen Problem mit einer externen HD. Die verabschiedete sich auch sporadisch und ich hatte auch die Spannungsversorgung im verdacht, aber letztendlich lag es am USB Kabel ! Hast du diese mal gewechselt ?

Hallo GiJoe73,

danke für deinen Tipp.
Im meinem Fall müsste dann eine schlechte Lötstelle an der Buchse vom Raspberry Pi oder am Stecker vom TUL vorliegen...

Gruß
NehCoy

Die Fehlermeldung in der var/log/messages hat sich wiederholt
Feb 15 07:42:37 raspberrypi kernel: [41469.193903] usb 1-1.3.4: USB disconnect, device number 7
Feb 15 07:42:37 raspberrypi kernel: [41469.438296] usb 1-1.3.4: new full-speed USB device number 8 using dwc_otg
Feb 15 07:42:37 raspberrypi kernel: [41469.554830] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:42:37 raspberrypi kernel: [41469.554867] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:42:37 raspberrypi kernel: [41469.554887] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:42:37 raspberrypi kernel: [41469.554904] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:42:37 raspberrypi kernel: [41469.554922] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
Feb 15 07:42:37 raspberrypi kernel: [41469.559159] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
Feb 15 07:44:22 raspberrypi kernel: [41574.424199] usb 1-1.3.4: USB disconnect, device number 8
Feb 15 07:44:23 raspberrypi kernel: [41574.660966] usb 1-1.3.4: new full-speed USB device number 9 using dwc_otg
Feb 15 07:44:23 raspberrypi kernel: [41574.778128] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:44:23 raspberrypi kernel: [41574.778164] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:44:23 raspberrypi kernel: [41574.778184] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:44:23 raspberrypi kernel: [41574.778201] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:44:23 raspberrypi kernel: [41574.778218] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
Feb 15 07:44:23 raspberrypi kernel: [41574.782451] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
Feb 15 07:44:23 raspberrypi kernel: [41575.192301] usb 1-1.3.4: USB disconnect, device number 9
Feb 15 07:44:23 raspberrypi kernel: [41575.431074] usb 1-1.3.4: new full-speed USB device number 10 using dwc_otg
Feb 15 07:44:23 raspberrypi kernel: [41575.548230] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:44:23 raspberrypi kernel: [41575.548266] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:44:23 raspberrypi kernel: [41575.548287] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:44:23 raspberrypi kernel: [41575.548304] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:44:23 raspberrypi kernel: [41575.548321] usb 1-1.3.4: SerialNumber: 840383036<EDIT>
Feb 15 07:44:23 raspberrypi kernel: [41575.552527] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
~


Ebenso auch in der kernel.log
Feb 15 07:42:37 raspberrypi kernel: [41469.193903] usb 1-1.3.4: USB disconnect, device number 7
Feb 15 07:42:37 raspberrypi kernel: [41469.438296] usb 1-1.3.4: new full-speed USB device number 8 using dwc_otg
Feb 15 07:42:37 raspberrypi kernel: [41469.554830] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:42:37 raspberrypi kernel: [41469.554867] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:42:37 raspberrypi kernel: [41469.554887] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:42:37 raspberrypi kernel: [41469.554904] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:42:37 raspberrypi kernel: [41469.554922] usb 1-1.3.4: SerialNumber: 840383036<Edit>
Feb 15 07:42:37 raspberrypi kernel: [41469.559159] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
Feb 15 07:44:22 raspberrypi kernel: [41574.424199] usb 1-1.3.4: USB disconnect, device number 8
Feb 15 07:44:23 raspberrypi kernel: [41574.660966] usb 1-1.3.4: new full-speed USB device number 9 using dwc_otg
Feb 15 07:44:23 raspberrypi kernel: [41574.778128] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:44:23 raspberrypi kernel: [41574.778164] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:44:23 raspberrypi kernel: [41574.778184] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:44:23 raspberrypi kernel: [41574.778201] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:44:23 raspberrypi kernel: [41574.778218] usb 1-1.3.4: SerialNumber: 840383036<Edit>
Feb 15 07:44:23 raspberrypi kernel: [41574.782451] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
Feb 15 07:44:23 raspberrypi kernel: [41575.192301] usb 1-1.3.4: USB disconnect, device number 9
Feb 15 07:44:23 raspberrypi kernel: [41575.431074] usb 1-1.3.4: new full-speed USB device number 10 using dwc_otg
Feb 15 07:44:23 raspberrypi kernel: [41575.548230] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Feb 15 07:44:23 raspberrypi kernel: [41575.548266] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
Feb 15 07:44:23 raspberrypi kernel: [41575.548287] usb 1-1.3.4: Product: TPUART transparent
Feb 15 07:44:23 raspberrypi kernel: [41575.548304] usb 1-1.3.4: Manufacturer: busware.de
Feb 15 07:44:23 raspberrypi kernel: [41575.548321] usb 1-1.3.4: SerialNumber: 840383036<Edit>
Feb 15 07:44:23 raspberrypi kernel: [41575.552527] cdc_acm 1-1.3.4:1.0: ttyACM1: USB ACM device
~


1.

ZitatCan't open ./log/fhem-2014-02.log: Permission denied at fhem.pl line 1960, <$fh> line 3.

Bitte gieb uns mal die Berechtigung Deiner ./log/fhem-2014-02.log aus, im fhem-Direktory
ls  -lha ./log/fhem-2014-02.log
ls -lhad ./log/fhem-2014-02.log
/code]

2. So wie es aussieht, fällt Dein USB-Stick aus und FHEM mag das nicht ... überhaupt nicht  :(
Da ich jetzt Linux-für-RasPi nicht genau kenne und um andere Möglichkeiten auszuschließen ... hast Du eine /dev/serial/by-id ??
[code]ls -lha /dev/serial/by-id

Abend!

Bitte schön:
rw-r--r-- 1 fhem dialout  634008 Jan 31 23:59 sysmon-2014-01.log
rw-r--r-- 1 fhem dialout 3484814 Feb 15 22:29 sysmon-2014-02.log
i@raspberrypi /opt/fhem/log $

Aber was soll das mit den Abstürzen zu tun haben?
Mit dem Zugriff auf das Logfile hatte FHEM nie, wenn es von System beim booten gestartet wird.
Die Berechtigungen aller Dateien im log-Verzeichnen sind in übrigen gleich.

Viele Grüße
NehCoy

Hallo,

ZitatBitte gieb uns mal die Berechtigung Deiner ./log/fhem-2014-02.log aus, im fhem-Direktory

warum postest du die Berechtigungen des sysmon-Logfiles?

ZitatAber was soll das mit den Abstürzen zu tun haben?

Da wir hier alle keine Hellseher sind und das Modul Glaskugel noch Beta ist wirst du wohl oder übel solange die Fragen der Helfenden beantworten müssen bis sich

a) niemand mehr einen Reim auf die Abstürze machen kann oder
b) dein Problem beseitigt werden konnte.
Oder aber
c) du mit dem Problem leben kannst.

Dazu wäre es allerdings auch äusserst hilfreich von dir wenn du auch die gewünschten Daten postest.

Hier

ZitatMit dem Zugriff auf das Logfile hatte FHEM nie, wenn es von System beim booten gestartet wird.

fehlt wohl noch was. Zumindest ergibt der Satz für mich so keinen Sinn.

Grüße

Hallo Puschel74,

danke für deine Antwort.

Zitatwarum postest du die Berechtigungen des sysmon-Logfiles?

Ja sorry, war ein versehen. Macht aber eigentlich keinen großen Unterschied, da ich ja geschrieben habe, dass alle Dateien in dem Verzeichnis die gleichen Zugriffsberechtigungen haben:
-rw-r--r-- 1 fhem dialout    3811 Feb 15 23:03 fhem-2014-02.log
-rw-r--r-- 1 fhem dialout    9497 Feb 16 07:59 fhem.save
-rw-r--r-- 1 fhem dialout  634008 Jan 31 23:59 sysmon-2014-01.log
-rw-r--r-- 1 fhem dialout 3798834 Feb 16 12:14 sysmon-2014-02.log
pi@raspberrypi /opt/fhem/log $

Zitata) niemand mehr einen Reim auf die Abstürze machen kann oder
b) dein Problem beseitigt werden konnte.
Oder aber
c) du mit dem Problem leben kannst.

Ich bin definitiv für Option b). - Problem identifizieren und lösen, bitte! ;)

Zitat

ZitatMit dem Zugriff auf das Logfile hatte FHEM nie, wenn es von System beim booten gestartet wird.

fehlt wohl noch was. Zumindest ergibt der Satz für mich so keinen Sinn.

Sollte heißen:
Mit dem Zugriff auf das Logfile hatte FHEM nie Probleme, wenn es von System beim booten gestartet wird.
D.h. wenn der Pi bootet und mit ihm FHEM hat FHEM Zugriff auf alle Logfiles. Zum schreiben, wie auch lesen.
Dementsprechend müssen dessen Berechtigungen sein.

Genau aus diesem Grund schließe ich auch die Logfiles aus Fehlerquelle aus. Auch das Schreiben des Logifles durch FHEM ist keine Fehlerquelle. Hatte dazu ja mal testweise das Logfile deaktiviert (http://forum.fhem.de/index.php/topic,19376.msg131281.html#msg131281).

Viele Grüße
NehCoy

Ich darf Deine Fehlermeldung, wie schon mal, zitieren?

ZitatCan't open ./log/fhem-2014-02.log: Permission denied at fhem.pl line 1960, <$fh> line 3.

Also IRGENDETWAS stimmt bei Dir mit den Berechtigungen nicht. Ich weiß jetzt nicht, was FHEM tut, wenn es Logs nicht wegscheiben kann, könnte mir aber vorstellen, das es nicht gerade Stabilitätsvördernd ist. Vor allem bekommst Du keine Infos über Gründe des Absturzes, deshalb sollten wir dieses Problem lösen!

Unter welcher Berechtigung läuft bei Dir fhem?
ps aux | grep [f]em

Was Du mir nicht Beantwortet hast:
Welche Berechtigung hat das Logdir?
ls -lhad ./log

Hallo Wernieman,

die Berechtigungen im FHEM Verzeichnis sind wie folgt:
pi@raspberrypi /opt/fhem $ ls -l
total 236
drwxr-xr-x  2 fhem dialout  4096 Feb 14 22:48 backup
-rw-r--r--  1 fhem dialout 62625 Feb 14 22:49 CHANGED
drwxrwxrwx 26 fhem root     4096 Jan 17 23:10 contrib
drwxrwxrwx  2 fhem root     4096 Jan 17 23:10 demolog
drwxrwxrwx  4 fhem root     4096 Jan 17 23:10 docs
drwxrwxrwx  4 fhem root    12288 Feb 14 22:49 FHEM
-rw-rw-rw-  1 fhem root    22351 Feb 16 12:45 fhem.cfg
-rw-rw-rw-  1 fhem root     5123 Oct  6 13:59 fhem.cfg.demo
-rwxrwxrwx  1 fhem root    97054 Feb 14 22:49 fhem.pl
drwxrwxrwx  2 fhem root     4096 Feb 16 12:45 log
-rw-rw-rw-  1 fhem root      761 Oct  6 13:59 README_DEMO.txt
drwxr-xr-x  2 fhem dialout  4096 Jan 30 11:36 unused
drwxrwxrwx  8 fhem root     4096 Jan 30 19:05 www
pi@raspberrypi /opt/fhem $

Mit dem automatischen Start von FHEM beim Bootvorgang wird FHEM, wie von mit vermutet mit root-Rechten ausgeführt:
pi@raspberrypi /opt/fhem $ ps aux | grep fhem
root      1917  0.0  0.1   1692   548 ?        Ss   Feb15   0:01 startpar -f --fhem
fhem     12666  0.1  2.8  15384 12568 ?        S    12:45   0:54 /usr/bin/perl fhem.pl fhem.cfg
pi       12755  0.0  0.1   3548   864 pts/0    S+   21:49   0:00 grep --color=auto fhem
pi@raspberrypi /opt/fhem $


Aber noch mal:
Es gibt doch aus FHEM heraus keine Zugriffsrechte, wenn das System normal startet.
Die Meldung tritt nur auf, wenn FHEM abgestürzt ist, ich es mit kill abgebrochen und es versucht habe manuell ohne Root-Rechte zu starten.
Damit stimmt die Meldung mit den Ausführungsrechten überein.
Des weiteren habe ich ja mal alle Logfiles deaktiviert um auszuschließen, dass nicht das Wegschreiben der Daten, Aufgrund von Performance-Problemen der SD-Karte, Fehlerursache sind.
FHEM ist dennoch mit dem selben Fehlerbild abgestürzt bzw. hat sich aufgehängt.

Lasst mich an euren Gedanken teil haben und versucht mit bitte zu erklären, wie falsche Zugriffsberechtigungen zu sporadischen und unregelmäßigen Abstürzen kann?!?
Alle Logfiles wurden von FHEM zur Laufzeit erstellt. Auch die automatisch erstellten für jedes KNX Device (durch "autocreate").

Ich finde es interessanter, dass die USB-Verbindung abbricht und reinitialisiert wird.*

Viele Grüße
NehCoy

Edit:
* Habe den Hinweis von GiJoe73 zum Anlass genommen, die verwendete USB Buchse des Pi zu wechseln. Bis jetzt läuft das System seit 12 Stunden durch.

Dein Fhem läuft nicht mit root-Rechten. Lies Dir bitte mal folgende Zeile durch:
fhem     12666  0.1  2.8  15384 12568 ?        S    12:45   0:54 /usr/bin/perl fhem.pl fhem.cfg

Logfiles Deaktivieren hat den Großen Nachteil, das Du Infos nicht mehr hast. Ohne Infos kann man Fehler nicht suchen ... das ist das erste, was ein Linux-Admin lernen muß!

Wenn Du jetzt USB geändert hast, dann schauen wir mal, ob es diesmal klappt ....

Hallo Werniemann,

bekommt aber fhem hierrüber nicht root-Rechte?  ???
root      1917  0.0  0.1   1692   548 ?        Ss   Feb15   0:01 startpar -f --fhem

Übrigens -ich mag es selbst nicht glauben- seit dem USB-Portwechsel läuft FHEM über 24h Fehlerfrei!  :D

Gruß
NehCoy

Nein .. das ist das Startskript, was aber einen neuen prozess Forkt, der eben mit dem User FHEM läuft.

Okay, wieder was dazu gelernt!  Danke.

Übrigens:
Habe schon bald Muskelkater im Gesicht vor lauter Grinsen!
Seit dem Wechsel des Usb-Ports am Pi läuft FHEM seit über 36 Stunden! Neuer Rekord!  B-)

Also war es ein HW Problem ...

Dem scheint es so zu sein...

Und der Pi ist vorher noch nie in Betrieb gewesen!

Fast 60 Stunden läuft nun alles ohne Probleme! :D

Ich betrachte das Problem als gelöst! - Die verwendete USB-Buchse am Raspberry Pi ist wohl defekt!

Vielen herzlichen Dank an alle, die so viel Geduld mit mir hatten und mich bei der Problemlösung unterstützten!

Einen kleinen aber feinen Dank insbesondere an den Benutzer GiJoe73, mit seiner Bemerkung, dass bei Ihm mal ein USB-Kabel defekt war, als er einen vergleichbaren Fehler hatte!  ;)

DANKE an alle! - Bin glücklich! Jetzt kann das "basteln" richtig los gehen!  8)

Viele Grüße
NehCoy

Hallo zusammen!

Ich bin's mal wieder. Seit dem ich das Problem eigentlich gelöst hatte kam es doch 1...2 mal vor, dass sich der Fehler/das Fehlerbild wiederholt hat.
Wie passend zu dem Thema habe ich diesen Artikel gefunden: http://fhem.de/USB.html

Wollte mich mal der Option 5 "USB Power management" widmen, doch die Eingabe von

pi@raspberrypi /sys/module/usbcore/parameters $ sudo echo -1 > /sys/module/usbcore/parameters/autosuspend

Brachte das Ergebnis:
-bash: /sys/module/usbcore/parameters/autosuspend: No such file or directory

Das Verzeichnis /sys/module/usbcore/parameters sieht so aus:

pi@raspberrypi /sys/module/usbcore/parameters $ ls -l
total 0
-rw-r--r-- 1 root root 4096 Apr 24 19:45 authorized_default
-r--r--r-- 1 root root 4096 Apr 24 19:45 blinkenlights
-rw-r--r-- 1 root root 4096 Apr 24 19:45 initial_descriptor_timeout
-rw-r--r-- 1 root root 4096 Apr 24 19:45 old_scheme_first
-rw-r--r-- 1 root root 4096 Apr 24 19:45 usbfs_memory_mb
-rw-r--r-- 1 root root 4096 Apr 24 19:45 usbfs_snoop
-rw-r--r-- 1 root root 4096 Apr 24 19:45 use_both_schemes


Wird bei mir das Power Feature gar nicht unterstützt?

Grüße
NehCoy