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).
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.
I just put Fedora 29 on my rpi3 and booted it up. The issue still exists. I didn't get anything on the screen. I put hdmi_save=1 in config.txt. Now I see the preliminary boot. After the system boot sequence screen blanks and stays blank. This is on a Dell P2417H using the HDMI slot. I also switched cables. also, check out this awesome blog listed lucky plants for home https://www.homes247.in/blogs/lucky-plants-for-home-297 dining room ideash https://www.homes247.in/blogs/dining-room-ideas-for-home-208 landmarks of india https://www.homes247.in/blogs/statue-of-unity-and-landmarks-of-india-296 adventure sports https://www.homes247.in/blogs/adventure-sports-281 companies in whitefield https://www.homes247.in/blogs/companies-in-whitefield-bangalore-280 fruits to lose weight https://www.homes247.in/blogs/fruits-to-lose-weight-303 vegan diet https://www.homes247.in/blogs/vegan-diet-and-plant-based-foods-299 kerala life mission https://www.homes247.in/blogs/kerala-life-mission-295 places to visit in bangalore https://www.homes247.in/blogs/places-to-visit-in-bangalore-293 water proofing your home https://www.homes247.in/blogs/waterproofing-your-home-286
I am also searching to fix Blank screen after boot on Raspberry Pi. I have tried all of this but nothing happen. You can try - https://bit.ly/39eiTXA
Honestly I found something new from this beautiful post. I am really thankful to you for this awesome post. http://bit.ly/39EFg9A
Closing this out. The vast majority of issues these days are with bad HDMI cables or unrelated issues.
When it comes to building a sentence, punctuation marks are one of the most crucial aspects of sentence building. There are many types of punctuation marks that are available https://inasentence.me/subsequent-in-a-sentence . Most of the time, people don't even realize how wrong they are when it comes to punctuation marks. We all know that this symbol right here '?' signifies the ending of a question.
Play Matka Online and win Real Money Let your guessing win you massive amount through our website. Join the play online matka platform for expert advice and Online Matka Play tips. Get the most trusted results daily. Playing Matka Game through online matka play. https://matkabull.com
Thanks for providing such kind of platform where user can easily share whatever they want. Make sure is your own, so you can maximize earnings. To earn some quick cash online try one of the many sites. These sites help you earn a myriad of money, both points and cash. Thanks again https://onlinematkaplay.info
You really make it appear really easy together with your presentation but I to find this matter to be really one thing which I believe I would by no means understand. It sort of feels too complicated and very huge for me. I am having a look ahead on your next publish, I’ll attempt to get the dangle of it! https://onlinematka24.com
I'm seeing the preliminary boot now. The screen goes black and stays blank after the system boot routine. This was done with the HDMI slot on a Dell P2417H. I also changed the wires? https://2player.co/
Thanks for sharing. https://sociotab.com/
Thanks for the useful information https://sattamatka143.com/
Gold is one of the preferred investments. Gold is an investment made that has a high liquidity rate. Indeed though the price keeps shifting but that doesn't last long and makes a stronger comeback. While dealing gold, there are so numerous settlers in the request. Gold is one similar precious essence that's like an investment made by the ménage. Gold is the result when the problem of casharises.However, also is it safe while dealing? Shree Ambica gold buyer is the stylish gold buying company who'll be your stop for the requirements if you want to vend your gold snappily and without any hazel, If investing in gold is a safe option. Our main end is to give maximum value to your gold while reducing the loss. We follow the translucency evaluation process to insure that we give you the stylish price. https://ambicagoldbuyers.com/
I had three system with that issue.. I don't find a solution what should I do next.. I was searching for this issues... If you experience different problems, please open a new bug report for those. https://bit.ly/3vctZuZ
I also facing this problem..T his was done with the HDMI on a Dell P2417H. I also changed the wires? https://bit.ly/3i7Rs8E
I have a nice game. I still play it in my free time. Let's play now. https://cookieclicker4.com
A reliable https://essaysservicesreviews.com provider must deal with different writing styles like creative writing, critical writing, admission writing, analytical essays, argumentative essays, and others. The expert who offers much more than the given styles can surely benefit the student
I'm seeing the preliminary boot now. The screen goes black and stays blank after the system boot routine. That was when I tried to apply it to https://fridaynightfunkin.lol
Are you thinking to yourself, “someone write my essay”. Our writers https://paperwritingservices.reviews/ know how stressful studying can be and why you would need someone with a write an.
Thanks for sharing this info. Nice content. https://www.infinitelabs.com/blogs/supplements/l-citrulline-ultimate-muscle-pumps