RPi3 nicht zugreifbar - scheinbar extrem hohe plötzliche Systemlast

[KölnSolar]

mit welcher karte ist es bei dir aufgetreten, markus?

ich hatte doch gar keine drin  , sondern über den USB-Stick gebootet.

Mir scheint, dass es nicht an der Hardware(Karte,Leser), sondern an der Software, also jessie, liegt.

läuft bei dir der hciuart.service, und/oder sollte er laufen und tut es nicht?

puhh, hab mal damit gespielt. Aber bem aktuellen Image  laufen tun 2*hci0 und hci-attach. k.A. was das ist 

Ich würde es nicht an jessie, sondern dem "RasPi-Kernel" die Schuld geben.

Ist der Kernel nicht in jessie "enthalten" Klär mich doch bitte über die Differenzierung näher auf.

[frank]

stimmt ja, du hattest keine sd drinnen. ok.

[Wernieman]

Jessi ist eine Distribution, d.h. Kernel + Software. Wenn man pauschal also Jessi "die Schuld" gibt, dann meint man das Gesammtsystem. Also Kernel + Daemons + Anwenungssoftware + .....

Wenn man dagegen den Kernel meint .. dann ist es ein Teilsystem.

Um mal einen Vergleich zu bringen (auch wenn er Hinkt):
Wenn mein Auto einen Platten hat, sage ich auch nicht, das es am Autohersteller liegt, sondern am Reifen.

Edit:
BTW:
Linux ist eigentlich auch "nur der Kernel". Alle Userlandprogramme, wie z.B: schon die Shell (bash) sind eigentlich schon nicht mehr Linux, sondern kommen aus dem Gnu-Umfeld. Deshalb heißt es eigentlich auch "Linux Gnu" .. aber man kann sich sehr darüber streiten
https://de.wikipedia.org/wiki/Linux#Die_Bezeichnung_GNU.2FLinux

[KölnSolar]

Danke. Dann meinten wir quasi das Gleiche und Du hast es noch etwas deutlicher eingegrenzt. 

[Wernieman]

Naja ... der Kernel vom "Team Debian" ist von der "Firma RasPi" verändert worden. Schließlich installiert man auch expliziet einen "RasPi-Kernel" und kein Debian-Kernel ... ;o)

Ich hatte mich nur gestöhrt an der "pauschalen" Schuldzuweisung an einm Team, welches eventuell gar nichts dafür kann ...

[KölnSolar]

Heute hat es mich dann mal wieder erwischt. Kein ssh, kein telnet, kein putty...... nur die "Textdarstellung" von fhem im Browser. Als letzten Eintrag konnte ich den disconnect meines 868CUL im Log sehen. Dieser Eintrag fehlte später im Log. War aber sicherlich nicht der CUL, sondern eher allgemein USB, USB-Hub, Spannung ? ? ? ? ?
Zum Glück konnte ich nach Stecker ziehen problemlos booten.
Und dass ich heute nach langer Zeit ein fhem-update gemacht habe, sollte auch nicht in die Ursache sein, aber wer weiß ?
Grüße Markus

[Wernieman]

Hast DU denn ausreichend:

USB, USB-Hub, Spannun

[KölnSolar]

Hi Werniemann,
mein Post war nur als Info und speziell für Frank gemeint, weil mein System bis gestern ca. 1 Monat problemlos lief. Ich bin mir ziemlich sicher, dass es bei mir an einem "Wackler" in der Kette Rpi-USBPort - Verlängerungskabel - passiver Hub-USB-devices+Verlängerung zum aktiven Hub mit einem weiteren USB-device liegt. Warum dann der Rpi(Jessie auf USB-Stick direkt an USB-Port des Rpi), und das auch nur teilweise, aussteigt, wird vermutlich ein Rätsel bleiben. Ich kann aber damit leben bzw. ein Tausch der Gerätschaften als Lösung wäre mir zu aufwändig.
Frank allerdings hat ja ähnliche Symptome. Und das, obwohl dessen System auf SD läuft.

Jetzt wollt ich grad nochmal recherchieren, weil ich im Hinterkopf hatte, dass die USB-Ports und der Kartenleser "irgendwie" eine physische/logische Verbindung haben und finde

Code Auswählen Erweitern

Im Februar 2015 wurde bekannt, dass der Raspberry Pi 2 Model B abstürzt, wenn er mit einem Xenon-Blitz fotografiert wird.[113] Die Raspberry Pi Foundation bestätigte dieses Verhalten. Verursacht wird
es durch ein Bauteil (,,U16"), das für die interne Spannungsversorgung zuständig ist. Dieses erzeugt aus den 5 V des Micro-USB-Anschlusses die intern benötigten Spannungen. Dazu wurde ein Chip ohne
Gehäuse gewählt und direkt auf die Platine gelötet. Wird der Chip angeblitzt, bringt der im freiliegenden Silizium auftretende photoelektrische Effekt die Spannungsregelung aus dem Takt. Die Folge ist
eine Spannungsschwankung, die zum Absturz des Raspberry führt. Problematisch ist dabei die durch einen Xenon-Blitz oder auch einen Laserpointer hervorgerufene rapide Helligkeitsänderung und
der enorme Lichtstrom. Andere helle Lichtquellen bereiten keine Probleme. Es werden verschiedene Lösungen diskutiert, wie künftige Revisionen unempfindlich gegenüber derartigen Lichtquellen
gemacht werden können. Als einfache Lösung empfiehlt der Hersteller, das Bauteil mit einem Tropfen elektrisch nicht leitenden und lichtundurchlässigen Klebers abzudecken.[114]
Und ähnlich seltsam ist das bei mir auch. Ich gehe die Treppe runter, vorbei an meinen USB-Hubs nebst freischwingenden Kabeln und Geräten, Tür öffnen, Licht einschalten, mache etwas im Kellerraum, wo der Rpi residiert, Licht ausschalten, Tür schließen, wieder vorbei an den Hubs und merke per Zufall dann irgendwann, dass fhem nicht mehr richtig geht. Daher mein Gedanke, dass ich den "Wackler" ausgelöst habe. Und wo ich gerade so überlege, wie ich ein Signal erzeugen kann, um den genauen Zeitpunkt des Teilausfalls zu bestimmen, kommt mir in den Sinn, dass eigentlich mein "check-jammer"(keine state-Veränderung seit 30 sek am RFXTRX), ein Klingeln über die FritzBox am Dect-Telefon auslösen müsste. LAN-Verbindung steht ja noch. Tat es aber auch nicht. Schau ich also beim nächsten Teilabsturz mal nach....

Also wie gesagt, mehr ein Erfahrungsbericht als ein Hilfeersuchen 
Grüße Markus

[Wernieman]

Code Auswählen Erweitern

pi-USBPort - Verlängerungskabel - passiver Hub-USB-devices+Verlängerung zum aktiven Hub mit einem weiteren USB-device liegt
Wie lang sind eigentlich die USB-Verlängerungskabel?

Es kann sein, das eine Störung im "Langen" Bereich von USB auch den direkt angeschlossenen USB-Stick betrifft, da im PI selber auch ein "Hub" drinsteckt. Es ist eigentlich nur ein USB-Baum. Eine Störung kann also bis zur Wurzel durchschlagen und damit auch den anderen Ast betreffen.

Ich habe z.B. eine Gembird-USB-Steckdose. Wenn diese Induktive-Lasten ausschalttet gibt es durch Induktive Spannungsspitzen ein Problem auf dem USB-Port. Dadurch erfolgt ein kompletter USB-Reset .....

[frank]

hallo markus,

gut zu wissen, dass es bei dir doch noch passiert, denn bei meinem nächsten "crash" wollte ich eigentlich das booten über usb-stick probieren. das hat sich ja nun leider erstmal erledigt.

das beschriebene lichtproblem ist schon ein hammer, aber das schliesse ich bei mir aus. mein pi hat jetzt schon an unterschiedlichen plätzen gestanden, mit und ohne gehäuse, auch direkt vorm fernseher. auch war er schon ganz allein zu haus, als es passierte.

ich habe übrigens auch einen cul direkt am usb des pi, ein cul433 von busware. allerdings hat der weiterhin seinen dienst getan, soweit ich mich erinnere. intertechno fernbedienung empfangen und aktoren bei dämmerung über fhem eingeschaltet. (gerade gesehen, antwort #7 bestätigt das)

dass eigentlich mein "check-jammer"(keine state-Veränderung seit 30 sek am RFXTRX), ein Klingeln über die FritzBox am Dect-Telefon auslösen müsste.

könnte das nicht auch bedeuten, dass der rfxtrx weiterhin normal seinen dienst erledigt? so wie bei mir der cul.
wie lässt du dein dect klingeln? ich nutze bei mir das modul FB_SIP, das ich immer im hinterkopf habe, da es damals ziehmlich schwierig war, die notwendigen perlmodule zu installieren.

sollte dein rfxtrx weiterhin am usb funktionieren, so kann der eigentliche usb strang ja nicht gestört sein, sondern nur der datenzugriff über usb auf den stick. also wahrscheinlich auch der kernel, wie wernieman bei mir schon spekulierte. eventuell hängt die sdcard ja auch am internen usbhub, womit unsere konstellationen dann doch sehr ähnlich wären.

allerdings bleibt immer noch die frage nach dem auslöser.
ziehmlich seltenes, unrythmisches auftreten, das anscheinend nur von 2 personen bemerkt wurde. hmm....

wenn ich pi im zusammenhang mit usb höre, muss ich eigentlich immer sofort an netzteil/spannungsversorgung denken. bei den seltenen ereignissen denke ich aber eher an gelegentliche spannungsspitzen oder spannungseinbrüche im netz. mal schauen, an eine usv denke ich schon länger.

gruss frank

[KölnSolar]

dass der rfxtrx weiterhin normal seinen dienst erledigt?

mein CUL definitiv nicht. Und der RFXTRX ? Weißt ja selber wie man in Panik gerät und so schnell wie möglich das System wieder zum laufen bringen will 

wie lässt du dein dect klingeln?

Ich machs über das FRITZBOX-Modul mit set Fritzbox ring ....

bei den seltenen ereignissen denke ich aber eher an gelegentliche spannungsspitzen oder spannungseinbrüche im netz.

ähnliche Gedanken hab ich auch immer, aber weniger aus dem Netz, sondern in meinem Keller durch das Einschalten der Energiesparlampe.

@Werniemann
2m (auseinandergeschnitten,durch ein Wandloch geführt und wieder zusammengezwirbelt ) + 1m;zwischen den Hubs 1m;am aktiven Hub 2m und angehängtem CO2-Sensor.

Es kann sein, das eine Störung im "Langen" Bereich von USB auch den direkt angeschlossenen USB-Stick betrifft, da im PI selber auch ein "Hub" drinsteckt. Es ist eigentlich nur ein USB-Baum. Eine Störung kann also bis zur Wurzel durchschlagen und damit auch den anderen Ast betreffen.

So denke ich mir das auch und dann mein Konstrukt 

Ich habe z.B. eine Gembird-USB-Steckdose. Wenn diese Induktive-Lasten ausschalttet gibt es durch Induktive Spannungsspitzen ein Problem auf dem USB-Port. Dadurch erfolgt ein kompletter USB-Reset .....

Was es alles so an Fehlerquellen gibt 

Was hältst Du von dieser (laienhaften)These zum Teilausfall: Was auch immer legt die USBs lahm. Somit ist das Filesystem(USB-Stick) nicht mehr erreichbar. Alles was auf Dateien zugreifen will geht nicht mehr. Der Kernel und Perl(nebst fhem-Modulen) sind aber im  RAM geladen und deshalb gibt es keinen "Vollabsturz" ?

Bin jetzt noch auf den Rpi-Watchdog gestoßen. Zumindest ließe sich damit einfach ein reboot erzwingen. Möchte aber beim nächsten mal gucken, was RFXTRX u. Fritte noch von sich geben....

[Wernieman]

Unix ist einerseits empfindlich, was den Verlust seiner root-Partition betrifft, andererseits läuft alles im RAM weiter. Hatte berufsmäßig einen Rechner, wo wir durch Log/Backup/Monitoring-Server im Nachhinein feststellen konnten, das 3 Monate lang die HDD kaputt war (Genauer 2 im Raid 1 Verbund). Diese 3 Monate lief er noch super, bis der RAM "voll" war ...

Wegen USB:
Genau aus dem Grunde bin ich (persöhnlich) gegen Verwendung von USB-Datenträgern für root (/). Bei Ausfall von / ist meistens der Rechner noch pingbar, aber ein einloggen nicht möglich, da dafür auf diverse Files (lesend) zugegriffen werden muss.  Ich weiß nur nicht, in wie weit fhem noch läuft, aber eigentlich müsste es eine Zeit X es überleben ...

[KölnSolar]

sooo, mal wieder diverse Abstürze bzw. Hänger in FHEM. Und heute hatte ich Geduld ein paar Sachen auszuprobieren.

Symptome: leicht verändert: kein Browserzugriff seit 11:47, letzter FHEM-log-Eintrag 11:43, letztes Datenlogging 11:47 von einem OBIS-event, SSH und putty-Zugriff problemlos, fhem-Prozess läuft mit 1,7%-3%(normal: 0,3-3% !) Last. dmesg ohne Eintrag.

keine Signalisierung über meine FritzBox, auch nicht nach abziehen des USB-RFXTRX(eigentlich hätte spätestens jetzt mein Telefon klingeln müssen, wenn fhem noch "richtig" läuft)

Mal wieder mit meinem Latein fast am Ende, versucht FHEM mit "fhem stop" zu stoppen. Kein Erfolg. Mehrfach probiert, Nix.

Also Geräte "Schuld". Erst hatte ich mein 1W am GPIO4 und den zugehörigen Prozess im Verdacht. Mal versucht diesen Prozess mit kill -9 zu stoppen: keine Chance.

Und dann kam mir mein immer verrückt spielender CO2-Sensor(alleine an aktivem USB-Hub, der an passivem USB-Hub nebst USB-Transceivern hängt) in den Sinn: Abgezogen und plötzlich klingelt mein Telefon !!! Und siehe da: nun hat sich fhem beendet mit folgenden Logeinträgen

Code Auswählen Erweitern

2017.01.27 11:34:19 3: WetterKoeln: 0 result(s) retrieved
2017.01.27 12:51:16 2: co20: read failed 0 (3)
2017.01.27 12:51:16 3: FRITZBOX: set Fritzbox ring 611 10
2017.01.27 12:51:18 0: Server shutdown
2017.01.27 12:51:29 1: BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection refused
2017.01.27 12:51:29 1: BlockingInformParent (FRITZBOX_Set_Cmd_Done): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection refused

fhem hat einen sauberen shutdown(incl. fhem.save) ausgeführt. Vermutlich das Resultat von vorher nicht funktionierenden, aber noch in irgendeiner Befehlsqueue hängenden "fhem stop" ? FHEM Neustart und alles OK.

@Frank: Hast Du auch den (Voltcraft-USB-CO2-Sensor) ?

@Werniemann: Meinst Du, dass es sich um die selbe Fehlerursache, nun aber mit anderen Symptomen handelt, sprich dieser (grundsätzlich undurchschaubare) CO2-Stick den USB-Hub wuschig macht ?

Beim nächsten mal werd ich als erstes den Stick ziehen und gucken, was dann passiert 

Grüße Markus

[Wernieman]

Wenn der Stick , wie alle alten Module, blocking-Zugriffe verwendet ... da hört es sich danach an.
Mit welchem Modul gehst DU denn an den Stick?

Wegen Fehlersuche, gehe mal, bei Problemen, wie folgt vor:
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373

[KölnSolar]

Das ging ja flott.
Mit dem 38_CO20.pm. 41-Seiten-Thread https://forum.fhem.de/index.php/topic,13166.0.html

Das Handling erfolgt nicht(so wie ich es sonst kenne) über DEVIO, sondern:

Code Auswählen Erweitern

CO20_Connect($)
{
  my ($hash) = @_;
  my $name = $hash->{NAME};

  return undef if( AttrVal($name, "disable", 0 ) == 1 );

  $hash->{USB} = Device::USB->new() if( !$hash->{USB} );

  if( $hash->{ID} =~ m/(\d.*):(\d.*)/ ) {
    my $dirname = $1;
    my $filename = $2;
    delete $hash->{DEV};
    foreach my $bus ($hash->{USB}->list_busses()) {
      next if( $bus->{dirname} != $dirname );

      foreach my $device (@{$bus->{devices}}) {
        next if( $device->idVendor() != $VENDOR );
        next if( $device->idProduct() != $PRODUCT );
        next if( $device->{filename} != $filename );
        $hash->{DEV} = $device;
        last;
      }
      last if( $hash->{DEV} );
    }

  } else {
    $hash->{DEV} = $hash->{USB}->find_device( $VENDOR, $PRODUCT );
  }

  if( $hash->{DEV} ) {
    $hash->{STATE} = "found";
    Log3 $name, 3, "$name: CO20 device found";

    $hash->{DEV}->open();

    $hash->{manufacturer} = $hash->{DEV}->manufacturer();
    $hash->{product} = $hash->{DEV}->product();

    if( $hash->{manufacturer} && $hash->{product} ) {
       $hash->{DEV}->detach_kernel_driver_np(0) if( $hash->{DEV}->get_driver_np(0) );
       my $ret = $hash->{DEV}->claim_interface( 0 );
       if( $ret == -16 ) {
         $hash->{STATE} = "waiting";
         Log3 $name, 3, "$name: waiting for CO20 device";
         return;
       } elsif( $ret != 0 ) {
         Log3 $name, 3, "$name: failed to claim CO20 device";
         CO20_Disconnect($hash);
       }

      $hash->{STATE} = "opened";
      Log3 $name, 3, "$name: CO20 device opened";

      my $interval = AttrVal($name, "interval", 0);
      $interval = 60*5 if( !$interval );
      $hash->{INTERVAL} = $interval;

      RemoveInternalTimer($hash);
      InternalTimer(gettimeofday()+10, "CO20_poll", $hash, 0);

      my $buf;
      $hash->{DEV}->interrupt_read(0x00000081, $buf, 0x0000010, 1000);

    } else {
      Log3 $name, 3, "$name: failed to open CO20 device";
      CO20_Disconnect($hash);
    }
  } else {
    Log3 $name, 3, "$name: filed to find CO20 device";
  }
}

und das pollende auslesen über einen internal_timer:

Code Auswählen Erweitern

CO20_poll($)
{
  my ($hash) = @_;
  my $name = $hash->{NAME};

  if(!$hash->{LOCAL}) {
    RemoveInternalTimer($hash);
    InternalTimer(gettimeofday()+$hash->{INTERVAL}, "CO20_poll", $hash, 0);
  }

  if($hash->{BLOCKED}) {
    return undef;
  }

  if( $hash->{manufacturer} && $hash->{product} ) {



    my $buf = "@".sprintf("%c",$hash->{seq2})."TRF?\n@@@@@@@@@";

    Log3 $name, 5, "$name: sent $buf / ".ord(substr($buf,0,1));

    my $ret = $hash->{DEV}->interrupt_write(0x00000002, $buf, 0x0000010, $hash->{timeout});
    if( $ret != 16 ) {
      my $ret2 = $hash->{DEV}->interrupt_write(0x00000002, "@@@@@@@@@@@@@@@@", 0x0000010, $hash->{timeout});
      $hash->{fail} = $hash->{fail}+1;
      Log3 $name, 4, "$name: write error $ret/$ret2 ($hash->{fail})";
      RemoveInternalTimer($hash);
      InternalTimer(gettimeofday()+30, "CO20_poll", $hash, 1);
      if($hash->{fail} >= $hash->{retries}) {
        $hash->{fail} = 0;
        CO20_Disconnect($hash);
        $hash->{RECONNECT} = 1;
        CO20_Connect($hash);
      }
      return undef;
    }
    if ($hash->{seq2} < 0xFF){ $hash->{seq2}++} else {$hash->{seq2} = 0x67};

my $data="";
for( $a = 1; $a <= 3; $a = $a + 1 ){
    $ret=$hash->{DEV}->interrupt_read(0x00000081, $buf, 0x0000010, $hash->{timeout});
    if( $ret != 16 and $ret != 0 ) {
      Log3 $name, 4, "$name: read error $ret";
    }
    $data.=$buf;
}
........

Wenn jemand mich mit Ideen zu sinnvolleren Stick-Handling(wo finde ich list_busses oder interrupt_read ?) versorgt, baue ich das Modul gerne auf "FHEM-Erfordernisse" um(bzw. stimme mich mit dem Modul-Maintainer dazu ab).