A long long time ago, I got a Raspberry Pi Model 2 and was waxing enthusiastic about using it more or less daily.
Then I “loaded it up” and it started crashing. ANY time it was over about 50% CPU and always when over about 75% CPU, the sucker would crash. Often with not much useful in the syslog file. Looked vaguely like it couldn’t “walk and chew gum” as it was worst when each processor “core” was loaded up with a different process. Especially if I was using a lot of swap. Clues, all. I suspected either low volts on heavy power draw (CPU and swap disk and memory and…) or general difficulty with handling swap well.
In general, testing showed that the Pi was not well suited to using multiple cores at once and swapping (with one test of parallel FORTRAN showing it would spread a task over 4 cores and get exactly nothing of benefit in return…)
I was dismayed, so went on to other things.
But as is my way, never let it go entirely. I’d “poke at it” from time to time. About 4? months ago I ran into a page saying “Do THIS to fix it!”… Time passes as I was not “in the mood” to go down that rat hole again.
But today I did. A slow day. I needed some “tech progress”. I wanted to use the R.Pi or know I needed to buy a different solution. OK, pop up that page and test it.
Now normally I’d just quote a partial and point to the page for the rest, however:
When I went to write this article, on 2 different systems, one of them the Pi itself using IceApe browser, I was slammed over into a Google Account Login Demand. Now since I don’t use a Google Account on the Pi or on the Tablet, I didn’t see much reason to log into one just to see a web page. So, for “another day” is an exploration of just why wanting to look at a web page results in a Google demand to “log in” to a Google Account… So I’m posting this from CentOS on the old 64 bit $80 or so machine ;-)
Here’s that page, just in case you, too, get a slap in the face from Google for wanting to see it:
Fixing Raspberry Pi Crashes
The most common crash I’ve experienced/heard about posts an error that says:
raspberrypi kernel: <1-1.1:1.0: eth0: kevent 2 may have been dropped
This happens to a lot of people who are torrenting (probably using transmission) and especially to external HDDs. It tends to turn up in /var/log/messages and/or /var/log/kernel and/or /var/log/dmesg. You can cat these to see if the error is there.
There are a couple of reasons that this happens and the following has been the way I have managed to fix it (Supposedly there is a bug fix in a distant future kernel release).
Memory isn't available fast enough and for some reason the kernel crashes.
I did two things to fix this.
1: Increase the number of min_kbytes by editing sysctl.conf
(using vim or nano or whatever)
Start by opening a terminal then type the following to edit the proper files.
sudo nano /etc/sysctl.conf
at the end of the file add the following line
vm.min_free_kbytes = 16384
*Note, if that doesn't help, try increasing the number
vm.min_free_kbytes = 32768
Then save and exit the file.
The second thing I did was to add an option to the boot command
sudo nano /boot/cmdline.txt
At the end of the line, add: smsc95xx.turbo_mode=N
Save, exit the file, and then reboot (sudo reboot)
Your usb hub has a problem where it is creating a feedback loop.
Tape over the +5V pin on the USB cord (You should use a multimeter to find it). Fixed, though a bit sketchily.
At this happened, hub or not, I just did #1.
As of now, I have set (using vi, not nano, as my editor)
vm.min_free_kbytes = 32768
Figuring why not go “all the way” up front and if it works, fine. I can always play with backing off later.
I also set:
but I’m going to back that out first and see if it really mattered.
IMHO, the basic problem is likely that the original 8K number was set for one core in the original Pi, and nobody thought to “fix it” for a 4 core Pi with 4 times the memory demand. So make it 32k.
As of now, the PiM2 has been up and running, very stable, for a few hours. All the time running a BOINC set of processes (3 cores at 100% most of the time, occasionally 4 cores). Before this would crash it in about 10 minutes, sometime less.
UPDATE: Just as I was set to hit “publish”, the Pi crashed again. OK, a lot longer than before, but not a full “fix”. The rest of the article is unchanged, but I’m going to try an even larger memory size next. Sigh.
I also launched 2 browsers while those were going. The machine didn’t crash, though the browsers would after a few minutes of doing “fancy things” like trying to post this posting… (WordPress is terribly “chatty” and a bit of a resource hog, especially posting, as every word gets spell checked again every minute or so). That might be more of a browser issue, as IceApe is a bit old and, er, deprecated. Epiphany is just a strange duck anyway and nobody seems to care about doing things that make it crash.
The “bottom line” for me is that this memory fix seems to have made the R.PiM2 now stable for heavy core use as a background processor. It isn’t quite tuned up yet enough to be run 100% “to the wall” and layer interactive things (like browsers) on top of that; but that’s OK. I usually divide those roles unless stress testing a box…
I guess now I can get back to all those Raspberry Pi Server projects I put on hold when the system wasn’t able to walk and chew gum at the same time ;-) ( I can’t bring myself to build systems on top of a box that crashes whenever the load goes over 75%…) now that it is able to run 3 cores “at the wall”, along with X-windows, and more, well, I’m “good with that”. Even if a bit more tuning is needed to make it as robust as an old VAX-780 when being hammered with tasks ;-)
Though I do note that this “difficulty” continues to point to the combined ethernet / USB / IO to Chip system as the weak spot. The I/O just isn’t balanced against the 4 cores. (Not really surprising as the original design balance was for 1 core). The implication is that for things like file servers and heavy I/O servers, the systems with a built in SATA are likely to be superior. Which implies that my present inventory of Pis is enough for any use that is not I/O intensive and my next “buy” will be something non-Pi.
Final note: Not sure what that whole “Google tongue down my throat login or nothing” behaviour was about, but I’m not the sort to put up with it. I’m happy to not visit “blogspot” web pages if that’s what it takes. Especially not sure why it would show up in the R.Pi browser (something thinking it is a tablet or picked up a Google Cookie somewhere or ???) If anyone “has clue” how to spike it, feel free to post a pointer. For now I’m happy to just mover over the old CentOS box and “flow around it”.
Despite what Google might think, the world is not all possessed of Google Accounts and even those that have one, don’t feel compelled to log into it constantly all day long just so Google can harvest our privacy. I’m happy to just not use Google “services” if that is what they want…