a bunch of wd_keepalive: unable to disable oom handling!. I'll have to try to force a crash again to see if the times of these coincide with the crashes...
wd_keepalive is a watchdog daemon described in man wd_keepalive. I do not think it is installed by default, so you are probably aware of it.
The OOM killer is a kernel feature intended to keep ...
Some places to look for errors:
The command dmesg will return most of the activity of the current boot.
dmesg returns every event after the boot and how long after the boot, in seconds.
The files /var/log/messages /var/log/syslog and /var/log/kern.log will return pretty much every event you could ever need to know to figure out what happened.
Check your power supply, it may not be able to provide enough current to keep the Pi running.
For example the recommended current supply for the Pi 2 and 3 model B's are as follows:
Raspberry Pi 2 Model B 1.8A
Raspberry Pi 3 Model B 2.5A
I/O failure is a common cause of this; processes suffering from such are
stuck in an uninterruptible sleep.
If this is widespread and includes critical processes, the entire system will stutter and stall -- although from a GUI perspective this may be exaggerated in that it is mostly the GUI that is stalling.
Such processes can be identified with diagnostic ...
wd_keepalive[n] is a thread from your watchdog process. N is an integer specifying the pid of whichever process it's actively watching. From what I can tell, the error is a bug in watchdog. Esentially it's either causing or receiving a fork bomb which then causes the system to crash.
Try disabling watchdog, and then run your make process.
If somebody finds this via search engines:
Re-compiling anything won't help at all, don't waste your time on that.
It's simply an issue with the Kernel and/or the Raspberry Pi firmware.
See here: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=159170
It was probably the polyfuse. Your shady power supply might have tripped it, unless it was from a reputable source.
Other than that, an accessory might have pulled too much power from the Pi, blowing the polyfuse.
For past logs, you can check out /var/log/kern.log if you're on Raspbian.
Yes, it may still be trustworthy. I would't worry about it. ...
it probably is a power supply problem.
The allowed voltage range is the normal one (for 5V logic) 5.0V ±5%
so its a the range between 4.75V and 5.25V.
Note that the lower limit of 4.75V is more a matter of many USB devices not working below that value than it is that the PI itself is that sensitive, especially as much of it (including the ethernet/hub chip, ...
This is a not good, as in bad:[, sign; it may have to do with a driver, possibly the driver for the Pi's SMSC ethernet controller, probably something more obscure since it likely isn't something that's affected many people.
Those console messages are from the kernel, and that final one only occurs once in the kernel source, in kernel/sched/idle_task.c (bare ...
It's pretty clear about there being no /dev/watchdog.
You may have to manually load the driver. Try:
sudo modprobe bcm2708_wdog
sudo modprobe bcm2835_wdt
And see if /dev/watchdog now exists. If it doesn't, or there are errors, immediately check tail -n 25 /var/log/syslog and/or journalctl -xn 25 to see if there is any explanation.
You can also double ...
This is almost certainly a power issue. The recommended power supply is at least 1 amp and 2 amps is what is suggested for proper performance. Powering the mouse and WiFi via the Pi, might be possible with a better power supply, however, I would suggest a powered USB hub. A quick search of this site will show many WiFi related problems can be traced to ...
Here is a small bash script that you can call with cron, for example every 30 seconds.
for ((i=COUNT; i>0; i--)); do
/bin/ping -c1 -n 220.127.116.11 >/dev/null 2>&1
[ $? -eq 0 ] && exit 0
This will look $COUNT times if ping returns without error. If so the script ...
If you decide to follow the unsupported "upgrade" from Jessie to Stretch you are expected to be able to resolve the many inconsistencies (including PHP5 and MySQL).
If you were satisfied with Jessie, restore from your backup.
Alternatively do a fresh install of Stretch (like almost everyone else).
You can use the serial debug interface to get a console on the Raspberry Pi. To use it you need a USB to Serial adapter like one from amzon - RPi USB/serial adapter. You do not need the most expensive one. I have made very good experience with one of the cheapest from China. To use the serial console you have to add a line to /boot/config.txt
I've faced a very similar issue i.e. Chrome or other software in general lags. If this answer doesn't help you, it might help others. I'd leave it here.
Follow the steps below, they have helped me, they might help you.
1 - Change the SD card. I'd prefer Sandisk 3.0.
2 - sudo purge unnecessary programs/software.
3 - systemd-analyze blame => Type the ...
Have you checked your system resources before starting the browser, and while it's starting up? I don't know anything about Redshift and QuickSynergy, but RPi does have limited resources, so worth verifying that you're not out of memory:
1) What happens if neither Redshift nor QuickSynergy are running when you start a browser?
2) If 1) works, start the ...
According the official doc
The Raspberry Pi 3 is powered by a +5.1V micro USB supply. Exactly how much current (mA) the Raspberry Pi requires is dependent on what you connect to it. We have found that purchasing a 2.5A power supply from a reputable retailer will provide you with ample power to run your Raspberry Pi.
Please check whether your power supply ...
Apparently, as of today, 8th January 2019, OpenELEC does not "support" the Raspberry Pi 3B+
LibreELEC on the other hand does. It's a very similar Kodi implementation to OpenELEC, but seems to be more frequent in its releases
Solved! It turns out there's another cron file I didn't know about, /etc/crontab. I took a look and found this:
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x ...
Okay, this is just ridiculous, although I already expected this to happen somehow.
Pro tip: If your Pi is not working, let it rest.
Just a few minutes ago, I plugged in the Pi in question since I was planning to resume troubleshooting. Of course it works fine now. I wasn't surprised at all. I forgot this happened before.
It has been unplugged for around 8 ...
My pi3B+ sdr project, powered with a 2.5 amp supply, had stability issues until I plugged keyboard, mouse, usb audio out and other 'stuff' into a powered usb hub, and plugged the rtl-sdr directly into one of the pi's usb ports. After plenty reading to select compatible models for the rpi, I now have two rtl-sdr devices that work, one noisier than the other, ...
One simple way to test for issues is to disconnect the motors (you could connect low-power lamps / LEDs instead to visualize what the RPi is trying to do). If you still get resets, it may be a software issue. If not, it's almost certainly power glitches.
Another test is to run a motor constantly from a separate battery in the vicinity of the RPi and see if ...
I have a strong hunch that @ChadG and @joan have identified the issue: power. RPi's are not known for their robust power supplies, and (we're guessing) you're using a battery for Pi power. That could easily compound the problem unless you've taken steps to isolate the RPi from the car and its motors. The solution for you is two steps:
Check & verify the ...
Try to reinstall it manually
$ cd ~
$ wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tgz
$ sudo tar -xzf Python-3.6.4.tgz
$ cd Python-3.6.4
$ sudo ./configure
$ sudo make
$ sudo make altinstall
All computers (not just the Pi) fail from time to time. Most of my Pi run for months at a time, without problem.
In many cases it is impossible to discover why, although you should check logs to see if there is a systematic error.
It is possible that it is a random hit from a cosmic ray!
Rather than embarking on a futile hunt avoid the problem. The ...
The big picture here is that this is a response to critical firmware or software not being found on the first partition of the SD card.
This means the card is being read, and is formatted correctly at least to the extent that the first partition has been found. If instead the formatting is completely wrong/corrupted, the response would be the same as if no ...
Not having the green ACT light flashing does not mean anything is wrong, it just means not much is happening, at least in terms of I/O to the SD card, which is what that light literally indicates -- i.e., it's possible for the system to be very busy and there to be no ACT light activity. It's mostly useful at boot, and for checking that the SD card isn't ...
Given the information provided, it's pretty much impossible to tell what's wrong. There are 3 things I'd suggest, in order:
Try flashing a new SD card and running from it.
Try running a vanilla system with no extra software installed, and without any extra hardware connected to the board (USB sticks and the like). Perhaps you're doing that already, in which ...
Mar 3 19:53:42 raspberrypi kernel: [ 94.463130] usb 1-1-port2: over-current change`
imply that somethings is wrong the the voltage that's being supplied to the drive. So there's a couple things that may be at work here.
The change from Wheezy to Jessie was drastic. So drastic that the foundation recommends not upgrading ...