Pi freezes while "Updating SDK" with ACT light on steady

Question

I've been following a guide for setting up an LCD touchscreen on the Raspberry Pi 2 B, but whenever I run

sudo REPO_URI=https://github.com/notro/rpi-firmware rpi-update

it freezes while updating the SDK. When it freezes the ACT LED is on steady (indicating the SD is being accessed?), and it is no longer possible to SSH or ping the Pi (no route to host). I end up pulling the plug. If I recall correctly, after doing this the Pi will no longer boot from the SD and I have always had to flash the SD again. I am just getting started so there is nothing to lose.

Details

Pi model: 2 B
OS: Rasbian Jessie (full desktop image)
SD: 16GB Samsung Evo (SDHC). I can't be sure it's genuine. It says "Made in Korea," but that could be a lie.

I have had some issues with the power (most likely the USB cables being too thin), but I do not believe that was the problem because the Pi got stuck updating the SDK three times (once it succeeded and I messed up another way). I've started using a cut-apart USB cable with the wires soldered back together (to reduce resistance from the wires). My multi-meter shows the Pi's supply is staying within 4.90-5.10V (thought I understand the multi-meter will show the average, meaning short drops or spikes will not be noticed). Finally, whenever the Pi freezes, the PWR light is on steady.

The only devices connected to the Pi were an Ethernet cable and of course the power supply.

Here's what my SSH session ended at:

pi@raspberrypi:~ $ sudo REPO_URI=https://github.com/notro/rpi-firmware rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10666  100 10666    0     0   8435      0  0:00:01  0:00:01 --:--:--  8438
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 4.1.13-v7+
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   167    0   167    0     0    120      0 --:--:--  0:00:01 --:--:--   120
100 47.9M    0 47.9M    0     0   129k      0 --:--:--  0:06:19 --:--:--  192k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 4.0.7+
 *** depmod 4.0.7-v7+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK

And here's what top was showing when it froze:

top - 10:35:45 up 24 min,  4 users,  load average: 0.69, 0.25, 0.25
Tasks: 136 total,   1 running, 134 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.4 us,  0.7 sy,  0.0 ni, 73.4 id, 25.4 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:    948108 total,   801388 used,   146720 free,    17688 buffers
KiB Swap:   102396 total,        0 used,   102396 free.   619492 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
 2680 root      20   0    4700   1744   1604 D   1.3  0.2   0:00.04 cp          
 2630 pi        20   0    5092   2164   1792 R   1.0  0.2   0:04.17 top         
   51 root      20   0       0      0      0 S   0.7  0.0   0:02.33 mmcqd/0     
 1805 pi        20   0   90476  24552  20276 S   0.3  2.6   0:11.30 lxpanel     
    1 root      20   0    5480   3912   2732 S   0.0  0.4   0:06.57 systemd     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd    
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.48 ksoftirqd/0 
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+ 
    6 root      20   0       0      0      0 D   0.0  0.0   0:00.04 kworker/u8+ 
    7 root      20   0       0      0      0 S   0.0  0.0   0:00.72 rcu_preempt 
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_sched   
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh      
   10 root      rt   0       0      0      0 S   0.0  0.0   0:00.01 migration/0 
   11 root      rt   0       0      0      0 S   0.0  0.0   0:00.02 migration/1 
   12 root      20   0       0      0      0 S   0.0  0.0   0:00.02 ksoftirqd/1 
   14 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:+ 
   15 root      rt   0       0      0      0 S   0.0  0.0   0:00.01 migration/2 

I've posted /var/log/syslog to pastebin.

I have not reformatted the SD card since then, so if there are any system logs I should post please ask for them. I may have attempted boot once since then (If I did it failed), so perhaps I should try again for the sake of "untouched" logs.*
^{*Murphy's Law: It'll work as soon as I retry for the sake of more debugging info.}

Please ask for any needed clarifications or more info. I've been working on this for two days and have no idea what the problem is.

Answer 1

Edit2: As per the OP's suggestion: I'll summarise the answer to say that some people are having issues with the particular 16GB Samsung Evo (SDHC) "Orange" {not "Pro"} card that they were using. Despite there being a possibility, which I'm not sure we have eliminated, that there may be fake models of the card in existence, the OP's one does seem to display the full, expected capacity. We have identified a strong link to this bizarre-sdcard-mmc-errors question - which makes a link to the RPi's firmware which should have been addressed (but perhaps this is a borderline case) in Issue 397 in the Official GitHub repository for that.

For the details of my contributions - read on:

---

The top output with the "D" = uninterruptible sleep (according to the top man page) indicators in the "S"tate column, suggests that Input/Output (hardware) operations are taking place - and as the highest ranking task is cp (copy) I think that your Pi is hung whilst accessing the SD card - and you say you have had to re-flash it before and you are not sure of it's, ahem, parentage.

Whilst it can take time for the RPi to read/write large files from/to any SD card for it to be doing so for so long does not bode well for the state of that card. Interestingly this is an RPi 2 so has four cores not one - and for everything to hang is less likely to be due to the processor usage to being 100% for ages compared to a RPi 1. indeed the load average: 0.69, 0.25, 0.25 over the last 1, 5 and 15 minutes suggests that is not the case.

The posted syslog is not showing anything significant but the last items are clearing out temporary user files which would happen during login so I think it is possible that we are not seeing any bad event logs - because by the time the event has happened it is no longer possible to write a log message out to the (faulty) SD Card...!

If you want to try again I'd suggest you ssh TWICE into the RPi from a PC and be running in the second session (as root) tail -F /var/log/* this will monitor EVERY log file in that directory and once the initial surge of the last lines from every file has passed by, THEN you might like to try again with the update... there is one issue with this suggestion in that you are likely to be running Raspbian Jessie with a systemd as your first process - and I do not know whether it will be maintaining log files in the same way that good ol' sysV init and the associated daemons would have done in the past. 8-(

P.S. +1 for checking your power supply voltages, as well as giving out the log data that you have got.

---

Edit: further consideration points out that the above may not catch the problem after all - though as you have something watching those log files being appended (the tail command) the data being caught can be coming from the write-cache for the file-system rather than the file-system itself so it may be visible - YMMV. One further place that it may show up is /dev/console which is not written to a physical file (but is something I always try to have on display on my Linux PCs' GUIs by the xconsole application)!

Answer 2

A similar problem occured on my Raspberry Pi 2 today. ACT LED did not indicate any activity (off)². Samsung 64GB microSDXC, Raspbian Jessie + some packages from Debian Stretch, rpi-update was working before. Physical Input/Output stopped working, SSH connection was dropped (possible to esablish connection to port 22 afterwards but could not continue negotiating SSH connection details).

Solution: I had to turn off "experimental GL driver" (raspi-config Advanced Options) (and removed "hdmi_drive=2" from /boot/config.txt *) which was working in dtoverlay=vc4-fkms-v3d mode* before. Did sudo rpi-update, switched on dtoverlay=vc4-kms-v3d afterwards - works for me now. I have not tried to change GL driver mode to dtoverlay=vc4-fkms-v3d yet.

*: for the sake of information completeness

²: so most probably there was no problem concerning the SD card in my case. Problem was reproduceable (tried 3 times).