Bug 1387733

I should have mentioned this:
I have used successfully the same hardware with various images from
raspberrypi.org .

Created attachment 1212916 [details]
tarball of /var/log from virgin boot

This is a tarball of /var/log taken after one boot from a virgin
image, Fedora-Mate-armhfp-25_Beta-1.1-sda.raw.xz .
Top dir in the tarball is 'log'.
File mtimes are somewhat screwy due to the RPi's lack of a built-in
hardware RTC.  (System clock is set at boot to circa Jul 25 15:59:40 .)

In case it makes any difference, my RPi has one non-standard bit of hardware --
a hardware RTC, battery-backed, on the GPIO pins.  But it's not configured
(seeing how I haven't been able to login ...).  And as I mentioned, I do not
have an NTP server.

This also occurs with a Raspberry Pi 3.

The 4.8.4-301.fc25 kernel does not help; kernel-4.9.0-0.rc2.git0.2.fc26 also does not help.

Sylvain Pasche has a workaround:

https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/message/3FHQUODJMJ4FVQFGCET2KFOHCAGGZOBD/

that restores basic console function but disables graphic acceleration.

Needs to be filed with the right component and tracker to actually be discoverable.

Please attach to this the dmesg output of boot with monitor and connection (DVI/HDMI/HDMI to VGA etc) details.

Created attachment 1214994 [details]
dmesg output for the failing case

Connected to Viewsonic VX2235 display (1680x1050 native resolution, DVI input).

I've also seen this issue with my pi2.  I've discovered that when using LXDE, I can ssh in and restart the LXDM service, and then the graphics system starts as expected.  It would seem that restarting the running DM service, SDDM, LXDM, etc, is enough to get X running.  Perhaps X is launching too early in boot, before the hardware or driver has settled?

(In reply to Jonathan Bennett from comment #8)
> I've also seen this issue with my pi2.  I've discovered that when using
> LXDE, I can ssh in and restart the LXDM service, and then the graphics
> system starts as expected.  It would seem that restarting the running DM
> service, SDDM, LXDM, etc, is enough to get X running.  Perhaps X is
> launching too early in boot, before the hardware or driver has settled?

Does not help with my pi3 - at last, not with GDM.  I can restart the dead gdm.service, but it goes into a loop (fails, then restarts itself) with messages like these in the journal:

Nov 06 08:42:14 RPi3-1 systemd-logind[555]: New session c333 of user gdm.
Nov 06 08:42:14 RPi3-1 systemd[1]: Started Session c333 of user gdm.
Nov 06 08:42:14 RPi3-1 audit[1029]: USER_START pid=1029 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:14 RPi3-1 gdm-launch-environment][1029]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 06 08:42:16 RPi3-1 kernel: i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
Nov 06 08:42:16 RPi3-1 kernel: i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
Nov 06 08:42:16 RPi3-1 kernel: i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
Nov 06 08:42:16 RPi3-1 kernel: i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
Nov 06 08:42:16 RPi3-1 kernel: i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
Nov 06 08:42:16 RPi3-1 org.gnome.Shell.desktop[1043]: glamor: EGL version 1.4 (DRI2):
Nov 06 08:42:17 RPi3-1 at-spi-bus-launcher[21958]: dbus-daemon[21963]: Activating service name='org.a11y.atspi.Registry' requested by ':1.664' (uid=42 pid=1043 comm="/usr/bin/gnome-shell " label="system_u:system_r:xdm_t:s0-s0:c0.c1023")
Nov 06 08:42:17 RPi3-1 at-spi-bus-launcher[21958]: dbus-daemon[21963]: Successfully activated service 'org.a11y.atspi.Registry'
Nov 06 08:42:17 RPi3-1 at-spi-bus-launcher[21958]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Nov 06 08:42:20 RPi3-1 gnome-shell[1043]: JS ERROR: TypeError: this.primaryMonitor is undefined
                                          LayoutManager<._updateBoxes@resource:///org/gnome/shell/ui/layout.js:461
                                          wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                          LayoutManager<._monitorsChanged@resource:///org/gnome/shell/ui/layout.js:495
                                          wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                          LayoutManager<._init@resource:///org/gnome/shell/ui/layout.js:277
                                          wrapper@resource:///org/gnome/gjs/modules/lang.js:178
                                          _Base.prototype._construct@resource:///org/gnome/gjs/modules/lang.js:110
                                          Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:213
                                          _initializeUI@resource:///org/gnome/shell/ui/main.js:151
                                          start@resource:///org/gnome/shell/ui/main.js:125
                                          @<main>:1
Nov 06 08:42:20 RPi3-1 gnome-shell[1043]: Execution of main.js threw exception: JS_EvaluateScript() failed
Nov 06 08:42:20 RPi3-1 gnome-session[1035]: gnome-session-binary[1035]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Nov 06 08:42:20 RPi3-1 gnome-session-binary[1035]: Unrecoverable failure in required component org.gnome.Shell.desktop
Nov 06 08:42:20 RPi3-1 gnome-session-binary[1035]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Nov 06 08:42:20 RPi3-1 org.gnome.Shell.desktop[1043]: (EE)
Nov 06 08:42:20 RPi3-1 org.gnome.Shell.desktop[1043]: Fatal server error:
Nov 06 08:42:20 RPi3-1 org.gnome.Shell.desktop[1043]: (EE) failed to read Wayland events: Connection reset by peer
Nov 06 08:42:20 RPi3-1 org.gnome.Shell.desktop[1043]: (EE)
Nov 06 08:42:20 RPi3-1 at-spi-bus-launcher[21958]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1024"
Nov 06 08:42:20 RPi3-1 at-spi-bus-launcher[21958]:       after 21 requests (21 known processed) with 0 events remaining.
Nov 06 08:42:20 RPi3-1 gdm-launch-environment][1029]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Nov 06 08:42:20 RPi3-1 audit[1029]: USER_END pid=1029 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:20 RPi3-1 audit[1029]: CRED_DISP pid=1029 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:20 RPi3-1 systemd-logind[555]: Removed session c333.
Nov 06 08:42:20 RPi3-1 gdm[21897]: Child process -1032 was already dead.
Nov 06 08:42:20 RPi3-1 gdm[21897]: Child process 1029 was already dead.
Nov 06 08:42:20 RPi3-1 gdm[21897]: Unable to kill session worker process
Nov 06 08:42:20 RPi3-1 audit[1064]: USER_AUTH pid=1064 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:20 RPi3-1 audit[1064]: USER_ACCT pid=1064 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:20 RPi3-1 audit[1064]: CRED_ACQ pid=1064 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Nov 06 08:42:21 RPi3-1 systemd-logind[555]: New session c334 of user gdm.
Nov 06 08:42:21 RPi3-1 systemd[1]: Started Session c334 of user gdm.

(In reply to Richard Ryniker from comment #4)

> Sylvain Pasche has a workaround:
> 
> https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/
> message/3FHQUODJMJ4FVQFGCET2KFOHCAGGZOBD/
> 
> that restores basic console function but disables graphic acceleration.

In addition to that (which is to blacklist "vc4" in
/etc/modprobe.d/blacklist-vc4.conf), I also had to add this to the "append"
line in /boot/extlinux/extlinux.conf:

    rd.driver.blacklist=vc4

Otherwise vc4 gets loaded by dracut and stays there, presumably because
kernel modesetting is used.  (Something I learned from Nvidia -- to use
the 'nvidia' driver, 'nouveau' has to be blacklisted.)

Both of these blacklistings are necessary -- else the blank screen syndrome.

*** Bug 1397529 has been marked as a duplicate of this bug. ***

*********** MASS BUG UPDATE **************
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs.
 
Fedora 25 has now been rebased to 4.9.3-200.fc25.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.
 
If you experience different issues, please open a new bug report for those.

Works for me with "Fedora-Minimal-armhfp-25-1.3". On Raspberry Pi 3.

(In reply to Jens Reimann from comment #13)
> Works for me with "Fedora-Minimal-armhfp-25-1.3". On Raspberry Pi 3.

I see no improvement with updated Workstation edition.  Text messages during
boot, then blank screen.  I suspect your Minimal edition may not try to do
whatever triggers the problem, but I have not tested Minimal.

As with earlier kernels, if vc4 is blacklisted a text screen can be used
to login.  Operation via ssh has always worked, and continues to work.

This is still an issue. We're awaiting more assistance from upstream.

Peter, is there an upstream bug report for this?  I looked on bugzilla.kernel.org but found only 23 Raspberry Pi bugs, plus one VC4
bug, but all are for other problems.

The upstream VC4 stuff is tracked here https://github.com/anholt/linux/issues

It looks like this is now fixed with F-26/4.11rc5 and later kernels but it would be good to get some wider testing to confirm. 

F-26 Alpha plus updates (or a F-26 nightly image) should have the fix it people could test and provide feedback

Does not work for me, using the nightly build Fedora-Workstation-armhfp-26-20170411.n.0-sda.raw

Full journal is here:

  http://ryniker.org/Fedora/arm/log_01

The relevant part looks to be:

Apr 11 23:22:57 localhost kernel: ------------[ cut here ]------------
Apr 11 23:22:57 localhost kernel: WARNING: CPU: 0 PID: 417 at drivers/gpu/drm/drm_atomic_helper.c:1122 drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper]
Apr 11 23:22:57 localhost kernel: [CRTC:65] vblank wait timed out
Apr 11 23:22:57 localhost kernel: Modules linked in: fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c crc32_arm_ce iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables joydev hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii brcmfmac brcmutil vc4 cfg80211 rfkill snd_soc_core dwc2 ac97_bus snd_pcm_dmaengine bcm2835_rng udc_core bcm2835_wdt bcm2835_dma leds_gpio nfsd auth_rpcgss nfs_acl lockd grace mmc_block snd_pcm
Apr 11 23:22:57 localhost kernel:  snd_timer snd soundcore drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sdhci_iproc sdhci_pltfm sdhci i2c_bcm2835 bcm2835 mmc_core pwm_bcm2835 sunrpc scsi_transport_iscsi
Apr 11 23:22:57 localhost kernel: CPU: 0 PID: 417 Comm: kworker/0:2 Tainted: G        W       4.11.0-0.rc5.git0.1.fc26.armv7hl #1
Apr 11 23:22:57 localhost kernel: Hardware name: Generic DT based system
Apr 11 23:22:57 localhost kernel: Workqueue: events vc4_seqno_cb_work [vc4]
Apr 11 23:22:57 localhost kernel: [<c0311700>] (unwind_backtrace) from [<c030c430>] (show_stack+0x18/0x1c)
Apr 11 23:22:57 localhost kernel: [<c030c430>] (show_stack) from [<c06396c4>] (dump_stack+0x80/0xa0)
Apr 11 23:22:57 localhost kernel: [<c06396c4>] (dump_stack) from [<c034c834>] (__warn+0xe4/0x104)
Apr 11 23:22:57 localhost kernel: [<c034c834>] (__warn) from [<c034c890>] (warn_slowpath_fmt+0x3c/0x4c)
Apr 11 23:22:57 localhost kernel: [<c034c890>] (warn_slowpath_fmt) from [<bf1923f0>] (drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper])
Apr 11 23:22:57 localhost kernel: [<bf1923f0>] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [<bf4ff7c8>] (vc4_atomic_complete_commit+0x5c/0xb4 [vc4])
Apr 11 23:22:57 localhost kernel: [<bf4ff7c8>] (vc4_atomic_complete_commit [vc4]) from [<c0364f00>] (process_one_work+0x254/0x42c)
Apr 11 23:22:57 localhost kernel: [<c0364f00>] (process_one_work) from [<c0366014>] (worker_thread+0x2b8/0x434)
Apr 11 23:22:57 localhost kernel: [<c0366014>] (worker_thread) from [<c036abe4>] (kthread+0x120/0x138)
Apr 11 23:22:57 localhost kernel: [<c036abe4>] (kthread) from [<c0307e58>] (ret_from_fork+0x14/0x3c)
Apr 11 23:22:57 localhost kernel: ---[ end trace 4b8e68ac66e78fe2 ]---

I ran into this situation but once I resized the partitions on the sd card it worked fine. This link provides instructions under Resizing the root partition:
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi?rd=Raspberry_Pi

(In reply to jplapointe22 from comment #20)
> I ran into this situation but once I resized the partitions on the sd card
> it worked fine.

It can be intermittent on some monitors, the partition resize won't have fixed it.

Proposed as a Blocker for 26-final by Fedora user jonha using the blocker tracking app because:

 Validates alpha criterion:

All release-blocking images must boot in their supported configurations.
Release-blocking ARM disk images must boot to the initial-setup utility.

*Violates

Can reproduce 100% with latest Fedora 26 development image on a Raspberry Pi 3 (Fedora Server edition).

This isn't a blocker, it's monitor HW specific, and often not reproducible.

The person who proposed this as a blocker should engage with the ARM SIG rather than just randomly proposing it with zero engagement.

> it's monitor HW specific

Just for reference, I've got the problem both with a cheap 5" HDMI screen ( http://r.ebay.com/WgH8Fg ) as well as with a standard Hisense HD TV which probably have almost nothing in common.

And if I can help testing or providing information I'd love to be helpful.

So there's some potential fixes that might improve this in kernel-4.11.7-300.fc26 (only this, not F25 yet). Please test (the kernel will work fine on F25 too) and let me know if there's any improvements

https://koji.fedoraproject.org/koji/buildinfo?buildID=911729

There was a round two on this patch that fixed up some issues, it's in the currently building 4.11.8 kernel [1]. I've tested a patch on 4 monitors that were previous instantaneous blank screen on the vc4 module load and it works now with that patch set on those so I think this should fix a large chunk of hardware out there now (I have no doubt that there will stuff be some HW with issues) but I think it will improve the use for a LOT of RPi users. 

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20249128

Proposed as a Blocker for 26-final by Fedora user pbrobinson using the blocker tracking app because:

 This bug affected a lot of Raspberry Pi users in Fedora 25, we finally have a fix that appears to sort the problem for a lot of problem devices previously. This would make the first out of the box experience greater for a lot of  the RPi users. The Raspberry Pi is a primary supported device for ARM.

Discussed at 2017-06-29 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-29/f26-blocker-review.2017-06-29-16.00.html . Accepted as a blocker, as a conditional violation of "All release-blocking images must boot in their supported configurations. Release-blocking ARM disk images must boot to the initial-setup utility" with certain monitor configurations.

Just spoke to Paul Whalen on IRC. He confirmed that the fix for this landed in kernel-4.11.8-300.fc26.

kernel-4.11.8-300.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-165671b9db

kernel-4.11.8-300.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-165671b9db

(In reply to Fedora Update System from comment #32)

Very much better.  There are still problems with displays such
as Dell's Ultra HD 4K Monitor P2415Q, which continues to manifest the blank screen problem and the "vblank wait timed out" issue.  Full log here:

  http://ryniker.org/Fedora/arm/log10

Ideally, the Raspberry Pi hardware would just drive a display like this at lower resolution.  Maybe some day, but I think it unreasonable to expect good fallback behavior for every device with capabilities beyond the design target of the Raspberry Pi.

With a smaller-resolution display, there is definitely usable display output.  GNOME on Xorg was better than the default GNOME, because the latter has keyboard input problems (start Terminal, no keyboard input; Ctl-Alt-F4 switches to another (not graphical) terminal that works; Alt-F1 switches back to the graphical terminal login screen; password is accepted, but still no keyboard input in the Terminal window).

Thank you to all who helped achieve this significant improvement.

Per #c33, and reports from roshi and satellit in the go/no-go meeting, marking VERIFIED.

kernel-4.11.8-300.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

The problem still persist with some displays. On a 4k Phillips the mode being selected is 2048x1080 and that doesn't work.

The workaround I found is:
1. place a 1080p edid file in /lib/firmware/edid
2. add kernel parameter in the bootloader config: drm_kms_helper.edid_firmware=edid/1080.bin

This fixed in on: kernel-4.11.8-300.fc26 as well as kernel-4.12.5-300.fc26

+1 for Richard's comment on limiting the max resolution to 1080p on the raspberry.

> +1 for Richard's comment on limiting the max resolution to 1080p on the
> raspberry.

This isn't open for vote, if you feel strongly about this please file a bug upstream [1] as we're only consuming the upstream.

[1] https://github.com/anholt/linux/issues/

Just tested Raspberry Pi3 with three different displays. All of them failed in a same manner with same output and blank screen.

Same result with:
Fedora-Xfce-armhfp-26-1.5-sda.raw.xz
Fedora-Xfce-armhfp-27_Beta-1.3-sda.raw.xz

See logs in #1494138:
Boot log: https://bugzilla.redhat.com/attachment.cgi?id=1331023
Cut error message: https://bugzilla.redhat.com/attachment.cgi?id=1331024

This issue is still present in Fedora.

Fedora-Xfce-armhfp-27_Beta-1.3-sda.raw.xz booted ok here. This is still happening on some displays, but has greatly improved since F25. Often a reboot is enough to get it working on problematic displays.

> This issue is still present in Fedora.

You don't report the make/module of the monitor you're seeing this on and what interface you're connecting it to. Saying "it's still present" isn't particularly helpful without that information.

This is a *REALLY* hard one to fix, it's a problem with the monitor, I've seen it where it fails on one boot, works on the next, but it's impossible for us to actually fix it 100% because it's impossible for us to test on 100% of all possible harwdware combinations, it's improved a *LOT* and now works on the vast majority of devices. Sometimes swapping the interface cable works. We're actively working with the RPi to improve it upstream as much as possible.

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.15.3-300.f27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

There is no question the situation is greatly improved from the time 16 months ago when this problem report was created.  My Raspberry Pi 3 works fine with the current (4.15.3-300) kernel when it uses an HDMI connection to "acceptable" display hardware.  This has been true for all of the recent kernels.

However, the failure continues to occur with some displays.  I experience it with an 8 megapixel (3820x2160) display.  An excerpt from my system journal is copied below.

The odd thing is that Fedberry, with its 4.14.14-1 kernel, does not have this problem.  It uses the higher-resolution display effectively, albeit at a reduced resolution of 1824x984.  I assume this resolution is the highest that the hardware can support.  My tests used the same Raspberry Pi and the same monitor connection, only the memory card in the Raspberry Pi was changed.

I see two likely reasons for this.  Either Fedberry has some kernel code that corrects this problem but is missing from Fedora 27, or something added after kernel 4.14.14-1 causes the problem.

There is more to do here.  Best would be to fix the current kernel to at least match the capability of Fedberry, but if that is not practical it would also be useful to avoid pollution of the journal with repetitive reports of this failure.

Jul 12 10:02:00 rpi3-1 kernel: ------------[ cut here ]------------
Jul 12 10:02:00 rpi3-1 kernel: WARNING: CPU: 2 PID: 499 at drivers/gpu/drm/drm_atomic_helper.c:1249 drm_atomic_helper_wait_for_vblanks+0x1d8/0x1f0 [drm_kms_helper]
Jul 12 10:02:00 rpi3-1 kernel: [CRTC:68:crtc-2] vblank wait timed out
Jul 12 10:02:00 rpi3-1 kernel: Modules linked in: rc_cec vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine snd_seq snd_seq_device brcmfmac snd_pcm brcmutil snd_timer hci_uart snd joydev btbcm soundcore btqca cec btintel hid_logitech_hidpp rc_core bluetooth cfg80211 drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt ecdh_generic bcm2835_thermal rfkill bcm2835_rng bcm2835_wdt hid_logitech_dj leds_gpio nfsd auth_rpcgss nfs_acl lockd grace sunrpc smsc95xx usbnet mii mmc_block dwc2 crc32_arm_ce sdhci_iproc udc_core sdhci_pltfm sdhci pwm_bcm2835 i2c_bcm2835 bcm2835 bcm2835_dma phy_generic i2c_dev
Jul 12 10:02:00 rpi3-1 kernel: CPU: 2 PID: 499 Comm: systemd-udevd Not tainted 4.15.3-300.fc27.armv7hl #1
Jul 12 10:02:00 rpi3-1 kernel: Hardware name: BCM2835
Jul 12 10:02:00 rpi3-1 kernel: [<c0311e80>] (unwind_backtrace) from [<c030ca28>] (show_stack+0x18/0x1c)
Jul 12 10:02:00 rpi3-1 kernel: [<c030ca28>] (show_stack) from [<c0a964c4>] (dump_stack+0x80/0xa0)
Jul 12 10:02:00 rpi3-1 kernel: [<c0a964c4>] (dump_stack) from [<c035143c>] (__warn+0xdc/0xf8)
Jul 12 10:02:00 rpi3-1 kernel: [<c035143c>] (__warn) from [<c0351494>] (warn_slowpath_fmt+0x3c/0x4c)
Jul 12 10:02:00 rpi3-1 kernel: [<c0351494>] (warn_slowpath_fmt) from [<bf342640>] (drm_atomic_helper_wait_for_vblanks+0x1d8/0x1f0 [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf342640>] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [<bf75d104>] (vc4_atomic_complete_commit+0x78/0xc8 [vc4])
Jul 12 10:02:00 rpi3-1 kernel: [<bf75d104>] (vc4_atomic_complete_commit [vc4]) from [<bf75d26c>] (vc4_atomic_commit+0x118/0x124 [vc4])
Jul 12 10:02:00 rpi3-1 kernel: [<bf75d26c>] (vc4_atomic_commit [vc4]) from [<bf3462f0>] (restore_fbdev_mode_atomic+0x84/0x1bc [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf3462f0>] (restore_fbdev_mode_atomic [drm_kms_helper]) from [<bf348968>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x48/0x7c [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf348968>] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [<bf3489f0>] (drm_fb_helper_set_par+0x54/0x64 [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf3489f0>] (drm_fb_helper_set_par [drm_kms_helper]) from [<c06fdbfc>] (fbcon_init+0x2e4/0x468)
Jul 12 10:02:00 rpi3-1 kernel: [<c06fdbfc>] (fbcon_init) from [<c07708c4>] (visual_init+0xc4/0x114)
Jul 12 10:02:00 rpi3-1 kernel: [<c07708c4>] (visual_init) from [<c0772264>] (do_bind_con_driver+0x26c/0x2d8)
Jul 12 10:02:00 rpi3-1 kernel: [<c0772264>] (do_bind_con_driver) from [<c0772648>] (do_take_over_console+0x174/0x1a8)
Jul 12 10:02:00 rpi3-1 kernel: [<c0772648>] (do_take_over_console) from [<c06fddd8>] (do_fbcon_takeover+0x58/0xc0)
Jul 12 10:02:00 rpi3-1 kernel: [<c06fddd8>] (do_fbcon_takeover) from [<c0370b78>] (notifier_call_chain+0x48/0x6c)
Jul 12 10:02:00 rpi3-1 kernel: [<c0370b78>] (notifier_call_chain) from [<c0370fcc>] (__blocking_notifier_call_chain+0x48/0x60)
Jul 12 10:02:00 rpi3-1 kernel: [<c0370fcc>] (__blocking_notifier_call_chain) from [<c0371000>] (blocking_notifier_call_chain+0x1c/0x24)
Jul 12 10:02:00 rpi3-1 kernel: [<c0371000>] (blocking_notifier_call_chain) from [<c06f57a4>] (register_framebuffer+0x230/0x274)
Jul 12 10:02:00 rpi3-1 kernel: [<c06f57a4>] (register_framebuffer) from [<bf34876c>] (__drm_fb_helper_initial_config_and_unlock+0x298/0x344 [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf34876c>] (__drm_fb_helper_initial_config_and_unlock [drm_kms_helper]) from [<bf348db4>] (drm_fbdev_cma_init_with_funcs+0xb8/0xf4 [drm_kms_helper])
Jul 12 10:02:00 rpi3-1 kernel: [<bf348db4>] (drm_fbdev_cma_init_with_funcs [drm_kms_helper]) from [<bf75d3fc>] (vc4_kms_load+0x98/0xbc [vc4])
Jul 12 10:02:00 rpi3-1 kernel: [<bf75d3fc>] (vc4_kms_load [vc4]) from [<bf758ff8>] (vc4_drm_bind+0xec/0x130 [vc4])
Jul 12 10:02:00 rpi3-1 kernel: [<bf758ff8>] (vc4_drm_bind [vc4]) from [<c07b1c10>] (try_to_bring_up_master+0x1ec/0x254)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b1c10>] (try_to_bring_up_master) from [<c07b2254>] (component_master_add_with_match+0xbc/0xe8)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b2254>] (component_master_add_with_match) from [<bf7590b0>] (vc4_platform_drm_probe+0x74/0xb0 [vc4])
Jul 12 10:02:00 rpi3-1 kernel: [<bf7590b0>] (vc4_platform_drm_probe [vc4]) from [<c07b97b0>] (platform_drv_probe+0x58/0xa4)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b97b0>] (platform_drv_probe) from [<c07b79c4>] (driver_probe_device+0x2cc/0x464)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b79c4>] (driver_probe_device) from [<c07b7be4>] (__driver_attach+0x88/0xf8)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b7be4>] (__driver_attach) from [<c07b5ac0>] (bus_for_each_dev+0x84/0x94)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b5ac0>] (bus_for_each_dev) from [<c07b6d18>] (bus_add_driver+0x1bc/0x234)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b6d18>] (bus_add_driver) from [<c07b87f0>] (driver_register+0xa8/0xe8)
Jul 12 10:02:00 rpi3-1 kernel: [<c07b87f0>] (driver_register) from [<c03020c4>] (do_one_initcall+0x12c/0x154)
Jul 12 10:02:00 rpi3-1 kernel: [<c03020c4>] (do_one_initcall) from [<c03de40c>] (do_init_module+0x60/0x1ec)
Jul 12 10:02:00 rpi3-1 kernel: [<c03de40c>] (do_init_module) from [<c03ddb58>] (load_module+0x219c/0x223c)
Jul 12 10:02:00 rpi3-1 kernel: [<c03ddb58>] (load_module) from [<c03ddd6c>] (SyS_init_module+0x174/0x18c)
Jul 12 10:02:00 rpi3-1 kernel: [<c03ddd6c>] (SyS_init_module) from [<c030829c>] (__sys_trace_return+0x0/0x10)
Jul 12 10:02:00 rpi3-1 kernel: ---[ end trace d435945f66aa6c9c ]---
Jul 12 10:02:00 rpi3-1 kernel: Console: switching to colour frame buffer device 256x80
Jul 12 10:02:00 rpi3-1 kernel: brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
Jul 12 10:02:00 rpi3-1 kernel: brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
Jul 12 10:02:00 rpi3-1 kernel: audit: type=1131 audit(1499868101.645:75): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 12 10:02:00 rpi3-1 kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:68:crtc-2] flip_done timed out
Jul 12 10:02:00 rpi3-1 kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:67:plane-20] flip_done timed out
Jul 12 10:02:00 rpi3-1 kernel: ------------[ cut here ]------------
Jul 12 10:02:00 rpi3-1 kernel: WARNING: CPU: 2 PID: 499 at drivers/gpu/drm/drm_atomic_helper.c:1249 drm_atomic_helper_wait_for_vblanks+0x1d8/0x1f0 [drm_kms_helper]
Jul 12 10:02:00 rpi3-1 kernel: [CRTC:68:crtc-2] vblank wait timed out

(In reply to Richard Ryniker from comment #42)
> There is no question the situation is greatly improved from the time 16
> months ago when this problem report was created.  My Raspberry Pi 3 works
> fine with the current (4.15.3-300) kernel when it uses an HDMI connection to
> "acceptable" display hardware.  This has been true for all of the recent
> kernels.
> 
> However, the failure continues to occur with some displays.  I experience it
> with an 8 megapixel (3820x2160) display.  An excerpt from my system journal
> is copied below.
> 
> The odd thing is that Fedberry, with its 4.14.14-1 kernel, does not have
> this problem.  It uses the higher-resolution display effectively, albeit at
> a reduced resolution of 1824x984.  I assume this resolution is the highest
> that the hardware can support.  My tests used the same Raspberry Pi and the
> same monitor connection, only the memory card in the Raspberry Pi was
> changed.
> 
> I see two likely reasons for this.  Either Fedberry has some kernel code
> that corrects this problem but is missing from Fedora 27, or something added
> after kernel 4.14.14-1 causes the problem.
> 
> There is more to do here.  Best would be to fix the current kernel to at
> least match the capability of Fedberry, but if that is not practical it
> would also be useful to avoid pollution of the journal with repetitive
> reports of this failure.

Can you file these details upstream [1] (one report for each separate issue). I don't have enough time to test Fedberry, work out what kernel/settings/patches/blah blah blah it has different to Fedora (I barely have enough time to support the RPi on the upstream kernel) but I suspect they're using the RPi foundation kernel sources (they will one day move to the the 4.14 LTS kernel on raspbian) that has a bunch of patches that should be upstream.

At least with a detailed upstream report, and it's better you reporting it upstream because you can answer questions directly rather than me acting as a message passer, we can hopefully get it improved moving forward.

Make note of the issue numbers here so that I can also track them.

[1] https://github.com/anholt/linux/issues

Can confirm, the problem is still there.
Latest Fedora 27 on Raspberry Pi 3.
I'm using a 4K Dell P2415Q display.

The problem re-appeared for me now using Fedora 27 (Minimal 1.6). With at least three different monitors. I can see the initial boot log, then the display goes blank.

After testing with a few setups I came up with:

Monitors not working:

* Dell P4317Q
* Dell P2417H
* NEC E231W
* Dell UltraSharp 38

Effectively none of the monitors I have access to works.

Workaround:

The old workaround from Fedora 25 [1] still works. My proposal would be to re-add this to the wiki in order to help people fix this

[1] https://fedoraproject.org/wiki/Architectures/ARM/F25/Installation#Known_Issues_.26_Usage_Tips

At least with the NEC I didn't have this issue in the past. I my assumption would be that this got worse again at some point.

My workaround was simply switching to the raspbian os. It has much a nicer integration with the Raspberry.

I have the same result with Fedora 28 - tested with: Fedora-Minimal-armhfp-28-20180327.n.0-sda.raw.xz

I did re-test this with Fedora Rawhide: Fedora-Minimal-armhfp-Rawhide-20180326.n.0

The results look better. I haven't tested all combinations again, but it did work on the P2417H.

(In reply to Arkadiy Night from comment #47)
> My workaround was simply switching to the raspbian os. It has much a nicer
> integration with the Raspberry.

not a useful comparison, a massively forked downstream kernel and a binary only non open source driver.... please keep the bug on topic and relevant.

(In reply to Jens Reimann from comment #45)
> The problem re-appeared for me now using Fedora 27 (Minimal 1.6). With at
> least three different monitors. I can see the initial boot log, then the
> display goes blank.

can you give more details of "re-appeared" in what kernel/release did it last work for, in general I've generally not had reports of regressions so I need more details, and will likely need more assistance in debugging this. Also could you try a different HDMI cable, I've had reports this (for reasons unknown to me) that at times changing the cable has fixed the problem, if it worked in the past and now doesn't a different cable could possibly be the difference.

(In reply to Jens Reimann from comment #49)
> I did re-test this with Fedora Rawhide:
> Fedora-Minimal-armhfp-Rawhide-20180326.n.0
> 
> The results look better. I haven't tested all combinations again, but it did
> work on the P2417H.

that's also weird, the difference between f28 and rawhide is mostly 4.16 rc4 -> rc6 so minor, although rc6 (now even rc7) is available in updates-testing so not far off so should be fixed RSN

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

This is still the case with the following images:

Fedora-Minimal-armhfp-28-1.1-sda.raw.xz
Fedora-Minimal-armhfp-Rawhide-20180813.n.0-sda.raw.xz

I have two monitors that had an issue in 28. A 21" Samsung with native 1600x1200 and a 7" Waveshare at 800x480. They both are working with rawhide 20180903.

(In reply to David Batzle from comment #55)
> I have two monitors that had an issue in 28. A 21" Samsung with native
> 1600x1200 and a 7" Waveshare at 800x480. They both are working with rawhide
> 20180903.

Sorry, meant to say with Fedora-Minimal-armhfp.

I just put Fedora 29 on my rpi3 and booted it up. Issue still exists. I dodn't get anything on the screen. I put hdmi_save=1 in config.txt. Now I see the prelimanary boot. After systemd boot sequence screen blanks and stays blank. This is on a Dell P2417H using the HDMI slot. I also switched cables.

And the workaround from #46 works

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Moving this to rawhide and adding tracker as even though in most cases these days the issue is more due to shitty HW and/or cables it comes up often enough that it's worth having here

This issue is gone with Fedora-Server-30-20190401.n.0.aarch64.raw.xz while it did still exist on the Fedora 29 aarch64 image.

Closing this out. The vast majority of issues these days are with bad HDMI cables or unrelated issues.