Tracking issue for Raspberry Pi 3B+ and the latest kernel

[samueldr]

Describe the bug

Using linuxPackages_latest with the current (as of 2018/08/19) sd images will not output to HDMI. Using the default kernel, 4.19, work.

See also:

• https://logs.nix.samueldr.com/nixos-aarch64/2019-08-19#1566239909-1566240443;
• https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi#Raspberry_Pi_3B.2B_HDMI_output_issues

[mmahut]

With the linuxPackages_latest my doesn't boot and get stack at Starting the linux kernel.... Let me know I can help you with debugging.

EDIT: Sorry, this is happening with LinuxPackages as well.

[samueldr]

With the linuxPackages_latest my doesn't boot and get stack at Starting the linux kernel.... Let me know I can help you with debugging.

"my" what? :) If this is not for the 3B+ (or 3A+ I assume would fail, too), it's likely to be another issue.

Under ideal conditions, you would have a serial log output from u-boot up to when it fails.

[WilliButz]

I noticed by accident, that on some (3 out of 5) 3B+ it takes a very long time (3+ minutes) until there is HDMI output after uboot.

This from one of the slow ones

# systemd-analyze critical-chain multi-user.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @3min 9.547s
└─network-online.target @3min 9.546s
  └─dhcpcd.service @3min 2.733s +6.808s
    └─basic.target @3min 2.608s
      └─sockets.target @3min 2.592s
        └─dbus.socket @3min 2.570s
          └─sysinit.target @3min 2.533s
            └─systemd-timesyncd.service @3min 1.095s +1.421s
              └─systemd-tmpfiles-setup.service @3min 969ms +73ms
                └─local-fs.target @3min 949ms
                  └─boot.mount @3min 870ms +65ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-NIXOS_BOOT.service @57.699s +2min 3.136s
                      └─dev-disk-by\x2dlabel-NIXOS_BOOT.device @5.635s

Here is one that boots faster:

# systemd-analyze critical-chain multi-user.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @17.003s
└─network-online.target @17.001s
  └─dhcpcd.service @10.014s +6.976s
    └─basic.target @9.992s
      └─sockets.target @9.976s
        └─dbus.socket @9.960s
          └─sysinit.target @9.883s
            └─systemd-timesyncd.service @8.482s +1.376s
              └─systemd-tmpfiles-setup.service @8.350s +75ms
                └─local-fs.target @8.329s
                  └─boot.mount @8.205s +110ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-NIXOS_BOOT.service @7.874s +287ms
                      └─dev-disk-by\x2dlabel-NIXOS_BOOT.device @6.689s

I also see a lot of these messages in the ringbuffer (only on the slower ones) and they stop right before there is hdmi output:

[   38.368317] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:116:crtc-2] flip_done timed out
[   48.608315] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:29:HDMI-A-1] flip_done timed out
[   58.848312] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:113:plane-20] flip_done timed out
[   69.088293] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:116:crtc-2] flip_done timed out

All of them use regular linuxPackages.

[WilliButz]

They are all the same version, have the same sd card model and are deployed with the same configuration.

@mmahut does your pi maybe also have hdmi output after a few minutes? :)

[mmahut]

@WilliButz yes, it does! I have a 3B.

[samueldr]

To be clear, I think the issue I'm tracking is with 19.03 only, unstable / 19.09 should have a recent enough u-boot. The issue comes from the u-boot shipped in 19.03 not knowing about the plus series of boards. (Unverified) It happens to work with the 4.19 kernel, but will not with the more recent (5.1+?) kernels.

Time to HDMI output on stable (19.03) is a known issue that has been fixed on unstable / 19.03. The necessary kernel modules were not present in the initrd. It meant that the system had to be fully mounted and booted until it could mode switch. It could take some time considering it first had to resize the root FS. See #63147 for details.

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[samueldr]

This shouldn't be an issue anymore for new deployments. Only old deployments were affected anyway.