Raspberry Pi 4 long term issue

Hello, 

my RPi 4 is running the latest Repetier-Server. I´ve a problem after letting it run for longer time. To be safe that i don´t get trouble to be able to reach it, i have to reboot it after 7-10 days. It starts that it doesn´t connect to a printer as flawless as the first days. Then the webserver is not reachable anymore. All little bit undefined, but a pain if i am running not sysnchronised long term prints on any of the printers.
If i wait too long for rebooting it will take like 20 min. for a reboot or it keeps hanging closing all, because it can´t close all threads of the device itself. Is there some memory issue known or anything similar which causes to kill it after a certain time?
Maybe any experience of anyone? 

Comments

  • I have no problems with long running pi so far. You can easily see memory usage with 
    free
    command. For next image I will disable swap file since swapping would in deed slow down critical processes. Should not happen. To do so now edit /etc/dphys-swapfile  and set CONF_SWAPSIZE=0 and reboot. Then you have no swap file.

    When you are now in slow state check memory usage with 
    ps aux
    and see if a program is claiming too much. One thing that can be is when started processes never terminate. Feel free to post ps aux report form a slow state if you are unsure. Then we can see if it is a lot of programs or one in particular. Good candidate for much memory is always chromium also I don't have a problem with it now.
  • Ok, thanks. I´ve freshly rebooted today as prevention. Will come back here, when i´ve the feeling that it might be interesting. Parallel i would give it a chance to disable swap file.
  • Just a side note better use

    ps aux | grep .

    when checking running programs. That way the command lines are complete and not cur at screen width.

  • I am experiencing the same thing, also on an RPi 4! I have to reboot every two or three days. Sometimes the prints wouldn't start, which is fine (and clear signal I need to reboot). And a few times it happened that my prints were trashed because it became unresponsive.

    I wonder since we both use RPi 4, would this be specific to this model only. Maybe it's overheating to a point it throttles the performance all the way down? I do have a massive passive heatsink case on it and it does get pretty hot at times...
  • In server bolt menu you can see if your pi was throttled and what temperature cpu has. Just for analysing the problem. My pi 4 with 4gb is now up 82 days, no throttleling and temperature 51°C but it has no enclosure so heat can escape easily.
    My 8gb pi 4 has a cooling fan, 42°C and up 11 days, no throtteling.

    Just that you have some references for temperatures.
  • Hello,
    after finishing the print i´ve seen that my repetier server is hanging somewhere. Even both printers are not responsive. On the webpage the one printer is showing it´s on but it switched of at the possible crash time.
    Please find attached the log files and the output of ps_aux.
    Even on the GUI it´s showing the printer is on. Putty was working. The crash was around 18:40. The connection.log was not logging anymore because the printer switched off via a relais. 
    But to be honest. This never happend before. It was the first time.
    If i try to restart via the GUI it pops away the GUI and switched to the console instead of rebooting. Putty is also not able to connect as it was a few minutes before.

    Would you even recommend to update the raspberry. I usually only do it, if necessary...i don´t wanna get any side effects.
  • i am not sure, why i don´t see the added files
  • Temperature was fine...the Pi is properly cooled with a fan and a big heat sink.
  • And another information: swap file size was already at 0. I was checking it to modify as you recommended.
  • Forum does not has upload function. Use paste.bin or dropbox or equivalent instead.

    When pi crashes unexpectedly it is often a defect on sd card. Does not mean necessarily that the sd card it self is defect, but that some blocks have wrong content and when it is used you get problems. So make a backup of /var/lib/Repetier-Server and reinstall the image. Copy folde rback and you have old settings but executables are all new installed.
  • I´ve checked the card on the PC, via fsck and via badblocks.
    All seems to be in good shape. 
    sudo badblocks -sv /dev/mmcblk0p1 -o mmcblk0p1.log
    Checking blocks 0 to 94207
    Checking for bad blocks (read-only test): done                                  
    Pass completed, 0 bad blocks found. (0/0/0 errors)

    I´ve used a quality SanDisk Exreme. It´s not even 3 months old. I am pretty sure it´s not the reason for the crash.
  • In syslog:
    Dec  8 18:40:47 Repetier-Server kernel: [533006.501593] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

    That seems when the printer disconnected. Don't have printers with cp210x serial chip so can't say much about what it writes. You can try explicitly with
    tail -f /var/log/syslog
    (stop with ctrl+C)
    connect and disconnect printer usb and see how such action would look like in log for comparison.

    ps aux shows server is running and no high load or memory usage, so looks fine.

    connected.log looked also fine until end of file. It could be that the message does not cause a real disconnect but somehow causes communication to stop like pretend to not receiving anything. Is the connection still green?

    Would a disable and activate printer in server make it communicate again? 
  • Yes, it was remaining green. I was switching on and off the printer several times (i mean the power supply). It was staying green. No reaction.
    Same like i saw on my other printer, when it started to freeze after a few days (from the other Discussion: https://forum.repetier.com/discussion/8294/mks-sgen-l-board#latest). 
    There it might be some start up communication problems. But i am wondering or i was wondering. Why after reboot it runs for several days, switching the printer on and off...and from one day to another. It starts also, going in the browser green...but the printer doesn´t get a message, because on the LCD there is no IP adress from server showing up...then i switch off and on again...and it´s in the browser red.
    Only this particular issue never happend on the Mega X. 
    So, i have no clue.
    The Mega X will get a new board the next days. It will be a STM32 (SKR Pro) and i´ll also change the board afterwards of the i3 Mega to a Robin Nano V2 or SKR 1.4 Turbo. I´ve all 3 already ready to install.

    I´ll check to play around littel bit and see what will be the output of the: tail -f /var/log/syslog
  • I'm pretty sure that some serial drivers are not working 100% correct and when some special errors happen they start acting strange. One of the reasons I have programmed for linux a simulation of removing usb plug. Then the driver normally gets restarted and works again. See in Printer Configuration->Connection->USB Reconnect on Timeout. These are really problematic issues because I'm not the author of these drivers and I also have no linux driver knowledge to analyse and fix such problems.

    STM32 is good. It has native usb - no problems known so far with that driver.
  • Yes, Printer Configuration->Connection->USB Reconnect on Timeout is set to "conservative", whatever this means, lol.
    Good, i´ll try a few things. The printers will be offline for a few days and i will play around with these settings, before removing the boards.
    Thanks for your support. 
  • It is just when it tries the usb reconnect. Conservative is on second timeout without response I think while early is on first timeout.
  • No probs here as well. Pi runs months now. Only reboot after a update. (40mm fan attached to my picase)
    But i dont use the repimage. i use raspbian as os.

    Everything is stable and snappy.
  • Found finally the problem. There seems to be an issue, i believe somewhere in programming design specs, between Marlin and Repetier Server. I´ve specified in Marlin a Tx buffer of 128 bytes. In RS there was a buffer suggested setting of 127 bytes, which should fit for datas send, if there are no other definitions.
    These forced during the prints some faults that messed up, even stopping prints in between, when printing large parts with long straight movements. 
    Finally i decreased in RS settings the buffer size for this printer to 63 bytes. Since them...all is running smooth. No faults in the logs, no restarts required. No hanging Pi after a week. Even the pi does restart without hanging after such a situation.
    So...if someone has a similar problem. Please try this solution, if the logs show communication / buffer issues. 
Sign In or Register to comment.