Bug 1387733 - Blank screen after boot on Raspberry Pi
Summary: Blank screen after boot on Raspberry Pi
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: armhfp
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1397529 (view as bug list)
Depends On:
Blocks: ARMTracker F26FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2016-10-21 17:16 UTC by Bruce Jerrick
Modified: 2019-05-26 22:31 UTC (History)
34 users (show)

Fixed In Version: kernel-4.11.8-300.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-06 22:51:31 UTC


Attachments (Terms of Use)
tarball of /var/log from virgin boot (241.35 KB, application/x-gzip)
2016-10-21 18:18 UTC, Bruce Jerrick
no flags Details
dmesg output for the failing case (33.53 KB, text/plain)
2016-10-28 13:49 UTC, Richard Ryniker
no flags Details

Description Bruce Jerrick 2016-10-21 17:16:49 UTC
Description of problem:
The recent Fedora 25 Beta Raspberry Pi spins boot, but at the end
of the systemd console messages, the screen goes (and stays) blank.

Version-Release number of selected component (if applicable):
(systemd is a WAG)
Fedora 25 Beta Raspberry Pi 2 spins dated Oct 5 2016 (image filenames
are given below).

How reproducible:
100%

Steps to Reproduce:
1. Copy current Fedora-*-armhfp-25_Beta-1.1-sda.raw.xz to SD .
2. Boot Raspberry Pi 2 from the SD .

Actual results:
The expected console messages, including the systemd messages after
"Welcome to ...".  Then the screen goes blank, and stays blank (with
backlight still on).
There is no response to keyboard except ctl-alt-del (which reboots);
that includes ctl-alt-fN (to go to a virtual console).

Expected results:
gdm screen or a login prompt on the display, or at least a virtual
console.

Additional info:
Raspberry Pi 2; Tontec monitor (1280x800) on HDMI; USB keyboard, USB mouse.
Happens with both Fedora-Minimal-armhfp-25_Beta-1.1-sda.raw.xz and
Fedora-Mate-armhfp-25_Beta-1.1-sda.raw.xz (Oct 5 2016).
Also happens when booting to single-user mode with the Minimal spin
(I haven't tested that yet with the Mate spin).
I do not (yet) have a DHCP server it can connect to; ditto for NTP.
Post-mortem on the SD filesystems shows the expected /var/log/*
(e.g., wtmp).

Comment 1 Bruce Jerrick 2016-10-21 17:27:05 UTC
I should have mentioned this:
I have used successfully the same hardware with various images from
raspberrypi.org .

Comment 2 Bruce Jerrick 2016-10-21 18:18:48 UTC
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 .)

Comment 3 Bruce Jerrick 2016-10-21 18:21:15 UTC
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.

Comment 4 Richard Ryniker 2016-10-26 15:25:19 UTC
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.

Comment 5 Peter Robinson 2016-10-28 10:10:40 UTC
Needs to be filed with the right component and tracker to actually be discoverable.

Comment 6 Peter Robinson 2016-10-28 10:13:10 UTC
Please attach to this the dmesg output of boot with monitor and connection (DVI/HDMI/HDMI to VGA etc) details.

Comment 7 Richard Ryniker 2016-10-28 13:49:36 UTC
Created attachment 1214994 [details]
dmesg output for the failing case

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

Comment 8 Jonathan Bennett 2016-11-06 02:44:46 UTC
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?

Comment 9 Richard Ryniker 2016-11-06 13:59:52 UTC
(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.

Comment 10 Bruce Jerrick 2016-11-12 08:45:54 UTC
(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.

Comment 11 Marc Muehlfeld 2016-11-22 18:02:56 UTC
*** Bug 1397529 has been marked as a duplicate of this bug. ***

Comment 12 Laura Abbott 2017-01-17 01:24:12 UTC
*********** 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.

Comment 13 Jens Reimann 2017-01-17 07:56:55 UTC
Works for me with "Fedora-Minimal-armhfp-25-1.3". On Raspberry Pi 3.

Comment 14 Richard Ryniker 2017-01-17 13:47:03 UTC
(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.

Comment 15 Peter Robinson 2017-01-17 14:27:02 UTC
This is still an issue. We're awaiting more assistance from upstream.

Comment 16 Richard Ryniker 2017-01-17 22:32:44 UTC
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.

Comment 17 Peter Robinson 2017-01-17 22:37:40 UTC
The upstream VC4 stuff is tracked here https://github.com/anholt/linux/issues

Comment 18 Peter Robinson 2017-04-11 10:13:18 UTC
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

Comment 19 Richard Ryniker 2017-04-12 15:28:33 UTC
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 ]---

Comment 20 jplapointe22 2017-06-13 19:34:53 UTC
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

Comment 21 Peter Robinson 2017-06-13 19:48:57 UTC
(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.

Comment 22 Fedora Blocker Bugs Application 2017-06-24 20:39:34 UTC
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.

Comment 23 J. Haas 2017-06-24 20:42:58 UTC
*Violates

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

Comment 24 Peter Robinson 2017-06-24 21:54:48 UTC
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.

Comment 25 J. Haas 2017-06-26 11:58:34 UTC
> 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.

Comment 26 Peter Robinson 2017-06-27 14:58:05 UTC
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

Comment 27 Peter Robinson 2017-06-29 16:13:03 UTC
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

Comment 28 Fedora Blocker Bugs Application 2017-06-29 16:15:21 UTC
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.

Comment 29 Adam Williamson 2017-06-29 19:19:33 UTC
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.

Comment 30 Stephen Gallagher 2017-06-30 14:31:22 UTC
Just spoke to Paul Whalen on IRC. He confirmed that the fix for this landed in kernel-4.11.8-300.fc26.

Comment 31 Fedora Update System 2017-06-30 15:01:43 UTC
kernel-4.11.8-300.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-165671b9db

Comment 32 Fedora Update System 2017-07-01 20:53:59 UTC
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

Comment 33 Richard Ryniker 2017-07-02 13:59:21 UTC
(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.

Comment 34 Adam Williamson 2017-07-06 18:23:10 UTC
Per #c33, and reports from roshi and satellit in the go/no-go meeting, marking VERIFIED.

Comment 35 Fedora Update System 2017-07-06 22:51:31 UTC
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.

Comment 36 Levente Tamas 2017-08-23 11:09:59 UTC
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.

Comment 37 Peter Robinson 2017-08-23 11:20:34 UTC
> +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/

Comment 38 František Zatloukal 2017-09-27 11:19:48 UTC
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.

Comment 39 Paul Whalen 2017-09-27 13:10:05 UTC
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.

Comment 40 Peter Robinson 2017-09-27 17:16:49 UTC
> 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.

Comment 41 Laura Abbott 2018-02-20 20:03:22 UTC
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.

Comment 42 Richard Ryniker 2018-02-21 18:33:26 UTC
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

Comment 43 Peter Robinson 2018-02-21 18:44:20 UTC
(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

Comment 44 Arkadiy Night 2018-03-13 14:01:24 UTC
Can confirm, the problem is still there.
Latest Fedora 27 on Raspberry Pi 3.
I'm using a 4K Dell P2415Q display.

Comment 45 Jens Reimann 2018-03-28 10:37:18 UTC
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.

Comment 46 Jens Reimann 2018-03-28 11:15:47 UTC
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.

Comment 47 Arkadiy Night 2018-03-28 12:00:17 UTC
My workaround was simply switching to the raspbian os. It has much a nicer integration with the Raspberry.

Comment 48 Jens Reimann 2018-03-28 12:34:43 UTC
I have the same result with Fedora 28 - tested with: Fedora-Minimal-armhfp-28-20180327.n.0-sda.raw.xz

Comment 49 Jens Reimann 2018-03-28 13:08:22 UTC
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.

Comment 50 Peter Robinson 2018-03-28 16:04:52 UTC
(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.

Comment 51 Peter Robinson 2018-03-28 16:08:56 UTC
(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.

Comment 52 Peter Robinson 2018-03-28 16:11:44 UTC
(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

Comment 53 Justin M. Forbes 2018-07-23 15:30:06 UTC
*********** 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.

Comment 54 Fred van Zwieten 2018-08-15 11:59:07 UTC
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

Comment 55 David Batzle 2018-09-06 02:24:17 UTC
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.

Comment 56 David Batzle 2018-09-06 02:29:48 UTC
(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.

Comment 57 Fred van Zwieten 2018-10-31 14:37:07 UTC
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.

Comment 58 Fred van Zwieten 2018-10-31 15:03:09 UTC
And the workaround from #46 works

Comment 59 Ben Cotton 2018-11-27 13:52:32 UTC
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.

Comment 60 Peter Robinson 2018-11-27 14:05:26 UTC
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

Comment 61 Fred van Zwieten 2019-04-02 14:26:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.