Hardware: AMD RX480 (XFX black edition Currently using amdgpu and testing how awesome dc code is coming along on a custom kernel. Shortly after the patches went through the other week that stopped the recent flickering, everything was (and still is) fine on kernel 4.17-rc1. Patches prior to rc2 (and onwards, including latest build and rc3 when tagged which are still broken for me) cause an unresponsive black screen on loading the kernel. Have to manually restart into another kernel. As far as I can tell, there were 3 patches to this area before rc2 was tagged https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=221bda4b5f1abfd74159d7bf3703affa62468030 but I tried reverting the one intended to fix 'black screens' without success. However, just after rc1 was tagged, there's a big chunk of patches https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8089f9f5a32938ddefb1767b8ee14bb7996e5e2f so it might have been something in that? If so, the problem still exists in what will become rc3 at the time of writing.
Extra info: Ubuntu 18.04 64bit Displayport connection to XG2402 (1920x1080, 144Hz)
Can you bisect?
Sorry for the delay. OK, so lots of news: I did see a patch in amd-staging-drm-next 354ee4815f52219fcd97d91269917261aac0518a ("drm/amd/display: Fix bug that causes black screen") that sounded ideal but I couldn't apply it cleanly since it's too out of sync. After a git bisect, I was pleasantly surprised that the 3 main patches between rc-1-rc2 for amd/display stuff were all fine. Looks like it's something else entirely. I tested out an ubuntu mainline kernel and it worked fine, so the problem is something different in my custom .config, I guess. Something that has been fine for 4.17-rc1 and kernels before that but suddenly needs to change for rc2 onwards. (Bug still present on 4.17-rc5 btw) last good: 5e747dd9be54be190dd6ebeebf4a4a01ba765625 first bad: 43838a23a05fbd13e47d750d3dfd77001536dd33 commit 43838a23a05fbd13e47d750d3dfd77001536dd33 Author: Theodore Ts'o <tytso@mit.edu> Date: Wed Apr 11 13:27:52 2018 -0400 random: fix crng_ready() test The crng_init variable has three states: 0: The CRNG is not initialized at all 1: The CRNG has a small amount of entropy, hopefully good enough for early-boot, non-cryptographical use cases 2: The CRNG is fully initialized and we are sure it is safe for cryptographic use cases. The crng_ready() function should only return true once we are in the last state. This addresses CVE-2018-1108. Reported-by: Jann Horn <jannh@google.com> Fixes: e192be9d9a30 ("random: replace non-blocking pool...") Cc: stable@kernel.org # 4.8+ Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jann Horn <jannh@google.com> I'm looking into my config options for RNG/random stuff, but this bug can probably be bounced somewhere more appropriate now :)
All sorted after finding the problem is known https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done/442956#442956 specifically: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82 As the patch addresses an important vulnerability (CVE-2018-1108), it shouldn't be reverted. Instead, it is advised to install things like rng-tools and increase entropy generation. As the work to solve this is documented and well underway, I'm happy to close this bug. Cheers.