Lockups on Pi 3 B (not B+)

[ewestbrook]

Are there any known incompatibilities with running this build on a Pi 3B (not a 3B+)?

I am experiencing freeze-ups reliably after a short time time under load. I installed with minimal changes (basically timezone and wifi, also plugged in wired ethernet).

I've also turned off XDM, and lockups still occur while running genup. Other distros run on this board indefinitely without problem. I've ordered a B+ to compare with.

Any troubleshooting ideas are very welcome!

[ewestbrook]

Caught in the act via ssh -- this was the last tailed text from /var/log/messages. Does it help us?

[sakaki-]

Hi @ewestbrook,

sorry to hear you are having problems with this ><

Been a while since I've run anything intensive on a 3B, but it looks like some sort of kernel /memory problem from your log. May be an issue with the 4.19.y kernel, as this has only recently been transitioned to, and hasn't had as much testing as the prior 4.14.y (particularly on 64-bit). Since you are running headless, have you commented the following lines from /boot/config.txt?

#dtoverlay=vc4-fkms-v3d,cma-256
#gpu_mem=128

and rebooted? This will save significant memory.

Best, sakaki

[ewestbrook]

Thanks for the response! I had already commented those lines. I guess I'll use a 3B+ for this build and keep my 3B stock for less cutting-edge things. :)

On a related note, what's the "proper" way to turn off NetworkManager in favor of using /etc/conf.d/net + /etc/init.d/net.xxx the traditional Gentoo way? I did

rc-update del NetworkManager default
rc-update del netmount default
rc-service NetworkManager stop
rc-service netmount stop

but NetworkManager still starts on boot, and it's not obvious to me which other service is in need of it.

Love what you've done here, by the way. So thorough! Saved me a lot of time versus going from scratch.

[sakaki-]

Before you give up on your 3B, you could try installing a 4.14 kernel, to see if that's the issue; would be a useful diagnostic. For example:

demouser@pi64 ~ $ sudo emerge -av1 =sys-kernel/bcmrpi3-kernel-bis-bin-4.14.90.20181222

and reboot.

To disable NetworkManager's "undead" behaviour under OpenRC, please see this post (and the comments thereto).

Best, sakaki

[ewestbrook]

Boot fails (black screen after rainbow) after kernel downgrade. But I'll try again.

Re: NetworkManager v. netifrc: Thanks, great pointer!

[sakaki-]

Apologies, just tried the downgrade myself. The issue is that some files (the dtbos) used to be 'owned' by sys-boot/rpi3-64bit-firmware (but are owned by the kernel more recently) and downgrading breaks because of that. The way around this is to do:

demouser@pi64 ~ $ sudo emerge --unmerge sys-kernel/bcmrpi3-kernel-bis-bin sys-boot/rpi3-64bit-firmware
demouser@pi64 ~ $ sudo emerge -v1 =sys-kernel/bcmrpi3-kernel-bis-bin-4.14.90.20181222

and then reboot (just tested this on a fresh copy of the image, it does then reboot cleanly into 4.14).

[ewestbrook]

Thanks again. I too noticed the colission files, but I missed the firmware files when I unmerged the previous. I now have a good 4.14.90 boot. Let's see how it does!

[ewestbrook]

I also did

echo '=sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226' > /etc/portage/package.mask/kernel.mask

to keep from accidentally upgrading.

[ewestbrook]

Much better! No lockups so far with the 4.14.90 kernel on the 3B.

[sakaki-]

Good news ^-^

So, unless you need the features of 4.19 specifically (e.g. camera module or h/w video codec support), you should be safe enough staying on 4.14 for now. Hopefully these rough edges will get ironed out over the next few months.

Best, sakaki

[ewestbrook]

Quite so! Very happy. Thanks again!

[sakaki-]

One minor point - be aware that your mask won't prevent an upgrade if another version of 4.19 is unmasked at the profile level sometime in the future (which may well happen). Something like:

echo '>=sys-kernel/bcmrpi3-kernel-bis-bin-4.19' > /etc/portage/package.mask/kernel.mask

would be a bit safer.

Best, S.

[ewestbrook]

Good point, and one I considered. My thinking was that I'd like to give any newer kernel a go, since we'd probably like to know if it things get fixed going forward. Do you think that's unlikely?

[sakaki-]

I think it's possible it'll be fixed, but more likely some other bugs (vc4 stuff etc.) will get addressed first, at which point I may unmask another version, and you may find yourself getting an upgraded (but still buggy wrt your issue) 4.19 kernel installed at the worst possible moment ^-^

Whereas, if you use the more generic >= mask, you can always then temporarily release it (or add an overriding package.unmask entry for a specific version) to knowingly try out an upgrade at a time of your choosing.

Ultimately though, as with all things Gentoo, the choice of how to proceed is yours!