I am developing a system that uses OpenCV with Python to access the csi camera, and PyGame for the GUI.

Due to the nature of the system (security program) it needs to be left unattended pretty much all the time, especially overnight.

I notice that when the system is left for long periods with no activity, this can cause everything to stop working, and terminal throws up all kinds of message from syslogd@raspberrypi messages that I don't know the meaning of.

This is on a Pi2 running Raspbian (relatively new version)

I will dump some of the errors here, and I hope someone can help explain why these errors occur, and what can be done to solve them.

The result from uname -r for me is Linux raspberrypi 3.18.9-v7 #1 SMP PREEMPT Fri Mar 20 11:10:23 UTC 2015 armv7l GNU/Linux In case that information is useful (as this is a kernel issue it would seem)

One message that stands out as a little different is something like: "Oops error 17 SMP PREEMPT ARM" which may tie in with the above result from uname -a

(Apologies it will have to be a screenshot as the froze up when I tried to copy/paste the messages)

enter image description here

enter image description here


some of the errors here, and I hope someone can help explain why these errors occur

That's literally just the tip of an iceberg. By "literally", I mean system log messages are classified into 8 levels of priority (see man logger or man 3 syslog), and, depending on configuration (see /etc/rsyslog.conf; it might also just be syslog.conf), the highest one or two of those will be set to broadcast to all terminals.1 This usually indicates there will be lower priority messages leading up to this. Where the lower priority messages will be also depends on configuration, but on Raspbian by default a copy of every message goes into /var/log/syslog.

So you should be able to read back through /var/log/syslog -- or where ever the equivalent is on your system -- and find those high priority messages intermingled with others. They should have more human decipherable timestamps such as Jun 30 07:31:34; the kernel ones in your terminal output are seconds since boot and they will be there too, which makes it easy to search for them (the string 29514.029590 probably doesn't appear more than once).

1. I think the kernel may also do this even on a system with no logger, which is why having a logger is a good idea.

Part 2...

What's in your log turns out to be pretty unfortunate, because it involves a "kernel paging request" error. This can have two causes:

1) Bad memory. Which you can't replace on the pi. You can confirm this by testing it; a common way to do that is with Memtest86, which is what the screenshot in that link is from. That isn't available for the pi, but apparently there is a memtester in Raspbian/Debian; some discussion of that here and here. They are fairly simple to use but take a while.

2) Otherwise, it's a kernel bug. This is kind of worse, because you can't fix it for $35. In fact, you probably can't fix it at all; just diagnosing it will take a certain level of technical expertise (if you think you are up to it you could start here, but do not be afraid to admit you are not; surgeons do not become surgeons over the course of a weekend, or even a month or a year).

  • After looking back through /var/log/syslog I think I have found the point in which the error first occurred. I shall edit my question and include some of these messages.
    – Aphire
    Jun 30 '15 at 13:07
  • Okay, see "Part 2" above.
    – goldilocks
    Jun 30 '15 at 13:26
  • Hmm okay, thats a pain. I will try the same SD card on another pi2 and see if its the bad memory problem, if its an actual kernel issue, I can only try and solve it, weather I do successfully who knows. However I have just stumbled across this article from a bitcoin stack exchange, that appears to have a similar problem, do you think this may aid me? bitcoin.stackexchange.com/questions/24120/… Thanks for your answers so far goldi
    – Aphire
    Jun 30 '15 at 13:47
  • Yes, absolutely try that. The only catch is there is a possibility something like this will cause the problem not to happen -- but as mentioned there just doing it will probably slow the system down substantially, so if that happens it is still no good as a fix. If it does work (it most likely will), it would hopefully provide a better clue, or at least a way to aquire one. Debugging the kernel is just like debugging anything else, although the kernel is on the "vast and complex" side and the options tool wise are limited.
    – goldilocks
    Jun 30 '15 at 13:53
  • Excellent. Well I am going to try and find a "proper" fix for the issue, but its nice to know I have something to fall back onto if I can't. Cheers for your help!
    – Aphire
    Jun 30 '15 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.