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.
"In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable". https://www.raspberrypi.org/forums/viewtopic.php?p=916911#p916911
Even the rpi-update documentation now warns "Even on Raspbian you should only use this ...
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 ...
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
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, ...
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.
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. ...
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
Here's the relevant part of the official docs.
Min and max:
GPU memory in megabytes, sets the memory split between the CPU and GPU; the CPU gets the remaining memory. The minimum value is 16; the technical maximum value 944 [for the RPi 4]. The default value is 64, values above 512 will not provide increased performance and should not be used.
You normally need to tell clam this is a new install using the freshclam command.
First create the file and dB directory
cp /usr/local/etc/freshclam.conf.sample /usr/local/etc/freshclam.conf
sudo nano /usr/local/etc/freshclam.conf
sudo mkdir /usr/local/share/clamav
Note in the editor set any preferences you want and change the paths on the above command ...
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, ...
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 ...
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 ...
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).
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
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 18.104.22.168 >/dev/null 2>&1
[ $? -eq 0 ] && exit 0
This will look $COUNT times if ping returns without error. If so the script ...
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
You shouldn't need to set it beyond the default value in the plain Raspbian /boot/config.txt. Max value is 128M.
Setting it beyond 128M can leave your Raspberry Pi 4B unbootable.
GPU memory on a RPi4B isn't used in the same way as on earlier Raspberries.
Which system log(s) do I check to see what the problem might be?
It is difficult to answer the question without knowing what operating system you are using. But most modern distributions use systemd, also Raspbian since version Jessie. So you may find the journal. Just have a look at it with:
rpi ~$ journalctl --pager-end
Or more detailed
rpi ~$ ...
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 ...