Load on CPU maxed, serial non-responsive

What is the problem?
Prints will halt, with terminal message Serial is non responsive , but indicates ready.
Octoprint complains of serial ready but non-responsive at some time in the print, BUT monitoring the CPU loading, monitored via ssh and htop, it shows that the CPU is near/above max 4X on a RPIv3 quad core.

What did you already try to solve it?

  1. video off
  2. safe mode
  3. pulled SD card and run, fsck -vf , on another computer, -- OK

  1. video
    I have turned off mjpg_streamer via the menu and it's load is eliminated, but the load is still high,( state: non-printing, non connected to printer, serving webpage ) is at 250%, maxed at some point when printing.
  2. safemode
    mode does not disable video, and menu for stopping is not functional in safe mode, but otherwise, no significant change in load, prior to commencing to print.
  3. SD card had no issuses from fsck

Additional information about your setup
OctoPrint version:
OctoPrint Version 0.13.0

OctoPi version
1.3.7 (2018-04-09), but this problem occurs also in 1.36


stock repitier


I have run it with and without serial log, same outcome, the most current is without.

or output on terminal tab, ...)

Please upload the log here or at least at a file hoster that doesn't require me to give them my mail address just to download the log. gist.github.com is also a good place for pasting that stuff.

at the command line/shell, run top and see what's taking all the CPU. On my Pi3 octoprint sits around 6-10% CPU while printing, mjpg_streamer is at about 6%.

ctrl-c to exit top.

Or use https://pastebin.com

ok it looks bad if you paste it wrong :smiley:
https://pastebin.com/qdMYaFB3 (not from me)

but what is nice that they have a good API.
Is a good plugin idea -> push a button -> automatic paste the log on pastebin -> and then you could paste the link in the forum :thinking:


  >>> from pastebin import PastebinAPI
  >>> logfile= open("pathToOctoprint.log").readlines()
   >>> x = PastebinAPI()
   >>> url = x.legacy_paste(logfile ,
   ...                     paste_name = 'Octoprint Log File',
   ...                     paste_private = 'unlisted',
   ...                     paste_expire_date = 'N',
   ...                     paste_format = 'bash')
   >>> print url

could work ...

I agree, a normal run is for me on a RPI_v3 quad core, 100% for the video, and then 5-10% for the rest of the processes, printer running and webpage being served. I have a crappy camera which requires a lot of CPU, but still plenty of headroom for octoprint.

I reported this in the body but using htop, a more verbose version of top.

The load is the python processes for octoprint.
/home/pi/oprint/bin/python /home/pi/oprint/bin/ocotprint serve --port=5000

I ran the same job on the same SW load and no problems, 9 hrs. The CPU load, this AM, was as expected. It was my crappy camera and a few percent elsewhere.

I am not surprised by the successful run as the last month with 1.36, this condition occurs 1 in 10 rate, ( ~~25 jobs starts). Earlier debugging , prior to the knowledge of the CPU load, were focused on serial , such as new USB cable, etc, but no change in serial halting.

Until I find the trigger to the problem, I will continue to document each step, however trivial to see of there is a repeatable set of conditions.

How strong is your power supply ?
maybe it provides not enough power for the usb devices

This setup has been in place for two years, and without fault till recent. The power supply is rated at 1.6 amps.

Electrical components are aging over time.
1.6 amps is to less for a raspberry P.
You have to use 2 amps or better 2.5.
The new official kits are delivered with a 2.5 amps power supply.

The reason is that if the cpu+gpu are idle a 1.6 amps power supply is enough.
But if the cpu have to do something or you have connected external devices 1.6 amps is not enough.
Most of the people i know use active usb hubs to outsource the power supply chain from the pi to the Hub to be able to use a 2 amps power supply because otherwise the Pi does strange things.