Arch Linux ARM v7 kernel/bootcode update on Raspberry Pi 3 i

[aroberts]

After a bit of googling I found this thread:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=11259
on the Raspberry Pi forums from 2012.

It looks like this issue has always been there. Perhaps different bootloader versions are better or worse.

On the PI/card which wasn't working I added:

hdmi_force_hotplug=1

to /boot/config.txt. That seemed to help. But then commenting it out didn't make the problem reappear...
I'll update my Pi's with this 'fix' and see what happens.

[aroberts]

Ok scratch that. I've had a failure with:

hdmi_force_hotplug=1

I saw it working before as I left the HDMI cable in.

[graysky]

OK, just to be clear, is the issue you're looking to reproduce the network suddenly just dropping? I believe the failure to reboot might be a 2nd issue all together.

[aroberts]

The network is not starting because the machine is not booting.
Its not just the network that doesn't start, the USB isn't initialized either, and there is no journal log. Plugging in a monitor after the failure, results in no signal.

This looks to be a bootloader issue that used to exist back in the early days, and has reoccurred in recent bootloader updates.

The bootloader handles config.txt, and that has a whole load of HDMI options. So I suspect the bootloader HDMI detection code is sometimes failing when there is no monitor attached, and results in a hang.

On a normal boot you see disk activity (as the bootloader's load), followed by a pause, and then more disk activity as linux loads.
When the system fails to boot, you don't see the secondary disk activity.

I was hoping the serial console would provide proof of this. But after enabling the uart (in config.txt I wasn't able to reproduce the hang.

The network being down was a symptom, and because the machine is headless its the only indication you see (apart from lack of disk activity). The network was not dropping, it was not coming back up after a reboot.

[graysky]

OK... my problem is different. The network just drops for me after it boots and is running. If I look at the LEDs, there is not link status shown... both lights near the LAN plug are out. If I look on the other end of the Pi3, the power is on (solid red) and the green blinks very infrequently. If I downgrade packages to the set from July 10th, it seems stable. When I update to current, the problem manifests but it's seemingly random. Some times, I have uptime for 2-3 days and other times, 10-15 min. I'd say that it was hardware, but the fact that the downgrade seems to prevent it makes me thing otherwise. Here is a list of packages that are suspect:
$this->bbcode_second_pass_code('', 'grep downgrade /var/log/pacman.log | awk '{print $5 $6 $7 $8}'
bison(3.0.4-3->3.0.4-2)
zlib(1:1.2.11-2->1:1.2.11-1)
cpupower(4.12-1->4.11-2)
curl(7.54.1-2->7.54.1-1)
dnssec-anchors(20170711-1->20170228-1)
expat(2.2.2-1->2.2.1-1)
elinks(0.13-19->0.13-18)
haveged(1.9.1-3->1.9.1-2)
libelf(0.169-2->0.169-1)
iproute2(4.12.0-2->4.12.0-1)
libarchive(3.3.2-1->3.3.1-5)
pcre(8.41-1->8.40-1)
popt(1.16-9->1.16-8)
linux-raspberrypi(4.9.39-1->4.9.36-1)
pacman(5.0.2-2->5.0.2-1)
python(3.6.2-1->3.6.1-1)
python2(2.7.13-4->2.7.13-3)
raspberrypi-bootloader(20170721-1->20170703-1)
raspberrypi-bootloader-x(20170721-1->20170703-1)
raspberrypi-firmware(20170721-1->20170613-1)
s-nail(14.9.0-1->14.8.16-2)
vim-runtime(8.0.0722-1->8.0.0628-1)
vim(8.0.0722-1->8.0.0628-1)
')

[aroberts]

Once mine are up the link is stable. I only ever have problems after a reboot, when it comes up or doesn't.
All 5 PI's are on 24/7, and the link is stable once up. They've been up 2 days 4hrs since last boot without issue.
3 are PI'3 running 32 bit, 1 is Pi3 running 64 bit, and 1 is PI B (v6l).
All have latest updates.

I'm preallocating IP addresses based on MAC address. and using a router on an internal network, which then connects to a second internet router. So Ip address assignments and NTP time doesn't rely on an external internet connection.

[aroberts]

Another day, another kernel update. Rebooted 5 32 bit headless PI's. Both v6l PI's came up ok, 2 of of 3 v7l (PI3) Pi's did not.
As originally stated had to remove ethernet lead to get them to boot, and then plug it in later.

[graysky]

$this->bbcode_second_pass_quote('aroberts', 'A')nother day, another kernel update. Rebooted 5 32 bit headless PI's. Both v6l PI's came up ok, 2 of of 3 v7l (PI3) Pi's did not.
As originally stated had to remove ethernet lead to get them to boot, and then plug it in later.

[graysky]

@aroberts - Update your system now... do the new systemd packages help? I am at 14/14 successful reboots with them...

[aroberts]

Interesting. I updated the systemd, it rebuilt initramfs, so I rebooted everything. All came back up.
I switched my SD card for the clean install card which reproduced the problem on almost every reboot.
Updated that, and it has gone 15 reboots without issue.

Looks like the updated systemd has resolved the issue. Not sure what having HDMI plugged in or not has to do with systemd though.

As I mentioned initially I first saw the issue on about July 7th, which was also a day systemd was updated 3 times...

Andrew