Pi Zero W freezes/crashes/hangs from day 1

Question

I have finally made the step and bought myself a Pi Zero W a few days ago. During the last 10 years or so, I have worked with multiple microcontrollers but never with a Raspberry computer. Hence, I would call my experience limited, so kindly bear with me.

I intend to build a nice little radio alarm clock, but that's for the future, I encountered issues with my Pi Zero W from the moment I plugged it in for the first time. During the last few days I tried following all suggestions from roughly 50+ forum pages and tutorials online as to how to troubleshoot my problem but nothing changed.

My setup

• Raspberry Pi Zero W headless (I added an ssh file and WiFi credentials to /boot in order to let the Pi directly connect to my network so I can access it via other devices without the need to ever plug in a monitor, keyboard or mouse, because I suspected them to be the victims, see below). Kernel: 4.9.59+

• Brand new Kensington 16 GB Micro SD Card class 10: https://www.amazon.de/dp/B0162YQEIE/ref=cm_sw_r_cp_tai_mJTBAbZGE928M. (Alternatively I used a SanDisk 32 GB class 10, which however almost always didn't boot at all. Merely the activity LED turned on after several flickerings and nothing else...)

• iPad Pro 10.5” Power Adapter (5.1 V with 2.4 A). (Alternatively another iPad adapter from a friend and an iPhone adapter with the same voltage but only 1 A, for testing purposes)

The issues

• I think the encountered problems are really just one problem and I suspect it to always be the same one. Here are a few issues that I had and the things I tried to solve them. For every new try I always used the suggested SD formatted application (Quick format) for Mac, as well as Etcher if needed.
• I copied NOOBS on the formatted SD card, it started, I selected to install Raspbian, it froze somewhere around 15 %. I retried 10 times with new copies with and without peripherals, it always froze, randomly between 1 % and 40 %.
• Same procedure with NOOBS over the network. Took ages and the next step was ready so I skipped:
• I etched Raspbian directly on the card and booted it up. Worked nice! I was happy. For 5 minutes. I connected to my WiFi manually, I enabled VNC and connected to the virtual desktop from another device, I unplugged all peripherals, continued in the VNC client: I connected to my Bluetooth speaker, I opened a Chromium website and started to stream a radio station to my speaker. It worked! It was a bit laggy but it worked. For 2 minutes, then it froze. The whole Pi.
• I set it up again, I found a stress test script which I am supposed to run for 10 minutes to see how my Pi performs. It did great, it only heated up to 44 °C, but after 7 minutes it froze.
• I found htop. From now on I use a third device to connect to the Pi via SSH and only show the htop list. Never did the memory reach full capacity in the following tests.
• I decided to use Raspbian Lite, which is probably more than enough for what I want. Boots up nicely, from now on I use the headless mode with the Pi directly connecting to my network on first boot, so never were there any peripherals attached. I changed my password, I started to do things with apt-get. Now it happened: randomly during apt-get installs or upgrades the Pi freezes. I try to install realvnc-vnc-server, it freezes, I tried to update, then upgrade, it freezes.

That's where I stopped yesterday. It is worth mentioning, that I leave the Pi running (after a hard reboot) all night long and it runs! Without any tasks initiated by me, the Pi just runs nicely. Even with the 1 A charger.

When freezing the activity LED either stays off or on, without flickering. I disconnect from power after 10 minutes. All other times I properly use the shutdown command.

I tried to get a crash log and after my last crash I opened /var/log/messages and I attached the relevant section below, I don’t know what happens, maybe someone understands it?

What I found out so far is, that the most common problem is power and the SD card. I find it hard to believe that this is causing my issues, too: the iPad charger provides more than enough power if I'm not mistaken, also everything I find online confirms that these adapters are good enough. The SD card is brand new, not too large, fast and I tried formatting it with the SD Formatter Tool properly (not only Quick format), but it didn't make a difference.

So I spent a couple of days with my Pi Zero W without even writing one line of code or connecting one single cable to it for my own project. Instead I try to make it run for more than 10 minutes whilst actually doing something. To be honest, I'm quite frustrated as this is not what I expected when I thought that this is a plug-in-and-be-happy solution...

I would very much appreciate any suggestions! My ultima ratio is to get a larger Pi instead, but I honestly hope that the Pi Zero W is also able to simply work?

Thank you very much!

Kind regards

Edit: I attached a console/terminal log during a crash after the command sudo apt-get install realvnc-vnc-server: https://image.ibb.co/c1HoUR/Crash.png

Here's the crash log:

Jan 28 22:13:21 raspberrypi kernel: [ 1674.420339] Modules linked in: cmac bnep hci_uart btbcm bluetooth brcmfmac brcmutil cfg80211 snd_bcm2835 rfkill snd_pcm snd_timer snd bcm2835_gpiomem fixed uio_pdrv_genirq uio ip_tables x_tables ipv6
Jan 28 22:13:21 raspberrypi kernel: [ 1674.425911] CPU: 0 PID: 15194 Comm: http Not tainted 4.9.59+ #1047
Jan 28 22:13:21 raspberrypi kernel: [ 1674.427853] Hardware name: BCM2835
Jan 28 22:13:21 raspberrypi kernel: [ 1674.429783] task: d9286d00 task.stack: d8226000
Jan 28 22:13:21 raspberrypi kernel: [ 1674.431745] PC is at handle_irq_event+0x14/0x4c
Jan 28 22:13:21 raspberrypi kernel: [ 1674.433725] LR is at handle_irq_event_percpu+0x58/0x68
Jan 28 22:13:21 raspberrypi kernel: [ 1674.435693] pc : [<c005ec4c>]    lr : [<c005ec28>]    psr: 80000193
Jan 28 22:13:21 raspberrypi kernel: [ 1674.435693] sp : d8227ad0  ip : d8227ae8  fp : d8227ae4
Jan 28 22:13:21 raspberrypi kernel: [ 1674.439653] r10: c05d1e40  r9 : d8226000  r8 : dac1e000
Jan 28 22:13:21 raspberrypi kernel: [ 1674.441598] r7 : 00000001  r6 : 00000000  r5 : dac223c0  r4 : 00000000
Jan 28 22:13:21 raspberrypi kernel: [ 1674.443557] r3 : 00000000  r2 : 0001869f  r1 : c08a68d0  r0 : 00000000
Jan 28 22:13:21 raspberrypi kernel: [ 1674.445501] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Jan 28 22:13:21 raspberrypi kernel: [ 1674.447499] Control: 00c5387d  Table: 183bc008  DAC: 00000055
Jan 28 22:13:21 raspberrypi kernel: [ 1674.671000] [<c005ec4c>] (handle_irq_event) from [<c005ec28>] (handle_irq_event_percpu+0x58/0x68)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.676444] [<c005ec28>] (handle_irq_event_percpu) from [<c005ec70>] (handle_irq_event+0x38/0x4c)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.681893] [<c005ec70>] (handle_irq_event) from [<c005ec28>] (handle_irq_event_percpu+0x58/0x68)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.687333] [<c005ec28>] (handle_irq_event_percpu) from [<c005ec70>] (handle_irq_event+0x38/0x4c)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.692772] [<c005ec70>] (handle_irq_event) from [<c0061c48>] (handle_level_irq+0x9c/0x130)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.698200] [<c0061c48>] (handle_level_irq) from [<c005dd5c>] (generic_handle_irq+0x30/0x44)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.703637] [<c005dd5c>] (generic_handle_irq) from [<c005e298>] (__handle_domain_irq+0x58/0xb8)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.709078] [<c005e298>] (__handle_domain_irq) from [<c0009420>] (bcm2835_handle_irq+0x28/0x48)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.714516] [<c0009420>] (bcm2835_handle_irq) from [<c05d575c>] (__irq_svc+0x5c/0x7c)
**Jan 28 22:13:21 raspberrypi kernel: [ 1674.719924] Exception stack(0xd8227bc0 to 0xd8227c08)**
Jan 28 22:13:21 raspberrypi kernel: [ 1674.722628] 7bc0: 00000000 00000002 00000000 c08a7760 d9124d00 da5e0000 00000002 d9286d00
Jan 28 22:13:21 raspberrypi kernel: [ 1674.727940] 7be0: c05d1910 da5e0000 c05d1e40 d8227c44 d8227c10 d8227c10 c0045f9c c0045fa0
Jan 28 22:13:21 raspberrypi kernel: [ 1674.733241] 7c00: 60000013 ffffffff
Jan 28 22:13:21 raspberrypi kernel: [ 1674.735854] [<c05d575c>] (__irq_svc) from [<c0045fa0>] (finish_task_switch+0x60/0x1d4)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.741039] [<c0045fa0>] (finish_task_switch) from [<c05d1910>] (__schedule+0x28c/0x5d0)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.746218] [<c05d1910>] (__schedule) from [<c05d1e40>] (preempt_schedule_common+0x20/0x30)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.751402] [<c05d1e40>] (preempt_schedule_common) from [<c05d1e98>] (_cond_resched+0x48/0x50)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.756584] [<c05d1e98>] (_cond_resched) from [<c05d369c>] (down_read+0x1c/0x48)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.761736] [<c05d369c>] (down_read) from [<c014f5b8>] (lookup_slow+0x40/0x140)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.764397] [<c014f5b8>] (lookup_slow) from [<c01529dc>] (walk_component+0x200/0x2cc)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.769504] [<c01529dc>] (walk_component) from [<c0152c20>] (link_path_walk+0x178/0x4bc)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.774650] [<c0152c20>] (link_path_walk) from [<c0153064>] (path_lookupat+0x94/0x118)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.779859] [<c0153064>] (path_lookupat) from [<c0154728>] (filename_lookup+0x9c/0xf8)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.785069] [<c0154728>] (filename_lookup) from [<c01547c4>] (kern_path+0x40/0x48)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.790422] [<c01547c4>] (kern_path) from [<c0592028>] (unix_find_other+0x38/0x228)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.795791] [<c0592028>] (unix_find_other) from [<c0593fd8>] (unix_stream_connect+0xe0/0x4b4)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.801175] [<c0593fd8>] (unix_stream_connect) from [<c04d0014>] (SyS_connect+0x74/0xa4)
Jan 28 22:13:21 raspberrypi kernel: [ 1674.806559] [<c04d0014>] (SyS_connect) from [<c000fe40>] (ret_fast_syscall+0x0/0x1c)
Jan 28 22:13:22 raspberrypi kernel: [ 1675.048823] ---[ end trace 94eeaae44c146674 ]---

Answer 1

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 something that can be handled, i.e., is fatal to the system, then there is nothing the software can do.

That's really just an educated guess though.

I'd like to be sure that it's not me doing something wrong, but the hardware actually being broken (which is veeeeery unlikely, I heard?)

It is unlikely, but no one tries to claim it is impossible either. In the four or five years I've been here, there have been a small handful of problems reported by people that seem to me easiest to explain as hardware defects or failures not related to misuse.

I believe Raspberry Pis are backed by a (one year) warranty most places, and there are also occasionally people here who've reported that they had one replaced by the retailer.

Keep in mind you aren't doing anything obscure, so the idea that you are repeatedly hitting a bug no one else hits also seems very unlikely. SD card corruption is a common problem on the Pi, but that does not look like such to me unless it involves some little chunk of kernel code. Since you claim this has happened with multiple installs that seems unlikely too; it would be worthwhile testing with another card if possible.

is there maybe a way to test it?

On PC's there's of course Memtest86; I've seen that catch bad RAM before. For the Pi there is a userspace application, memtester, available through Raspbian:

https://raspberrypi.stackexchange.com/a/2073/5538

Since it runs in userspace though, there are a few problems:

• Obviously you need to run the OS without it crashing.

• Presumably it can't test kernelspace, and from the looks of things that's where your problem is occurring.

I presume that the kernel accesses actual physical addresses on the Pi and always installs itself in the same place. If the exception log you get running the same kernel is always the same (or, using different kernels, always seems to involve the same addresses), this is a pretty good clue that it is bad RAM.

Outside of really digging into the kernel code though, you can't really prove this isn't a hardware defect (including something other than the RAM), so it is up to you how far you want to go.