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
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.
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 ...
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 ...
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'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 ...
This was indeed a power supply issue: unable to supply 2.5A reliably without dipping.
A clue is the lightning bolt icon that appears in the top right of the screen.
As Dr_Bunsen suggested:
It would crash when performing heavy tasks, the CPU draining more power and causing a voltage drop on the supply. Also, dmesg is useful for diagnosing problems, ...
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 126.96.36.199 >/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
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 ...
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 ...
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 ...
First thought: How often is the yellow read/write LED on the pi flashing or 'always on' when the freezes occur? I surf with chromium and often have 15 tabs, or more, open. Depending on the sites (the default gmail page uses lots of memory and you should use their basic html page instead), any more tabs, and the Memory is used up (checking it with gnome-...
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
Quoting myself: That's possibly corruption in kernel space; it probably isn't a bug since other people would be having similar problems (you are using the kernel currently being distributed as stable, 4.9.59+). You could have a zero with a RAM defect.
I guess it could be something else hardware related since an IRQ seems to be involved; if it is not ...
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 ...