Duncan posted on Mon, 16 Aug 2021 07:58:37 +0000 as excerpted: > Mikael Pettersson posted on Tue, 03 Aug 2021 08:54:18 +0200 as > excerpted: >> On Mon, Aug 2, 2021 at 8:29 PM Duncan <j.duncan@xxxxxxx> wrote: >>> Mikael Pettersson <mikpelinux@xxxxxxxxx> wrote... >>> > Booting 5.14.0-rc4 on my box with Radeon graphics breaks with >>> > >>> > [drm:radeon_ttm_init [radeon]] *ERROR* failed initializing buffer >>> > object driver(-19). >>> > radeon 0000:01:00.0: Fatal error during GPU init >>> >>> Seeing this here too. amdgpu on polaris-11, on an old amd-fx6100 >>> system. >>> >>> > after which the screen goes black for the rest of kernel boot and >>> > early user-space init. >>> >>> *NOT* seeing that. However, I have boot messages turned on by >>> default and I see them as usual, only it stays in vga-console mode >>> instead of switching to framebuffer after early-boot. I'm guessing >>> MP has a high-res boot-splash which doesn't work in vga mode, thus >>> the black-screen until the login shows up. >> >> Yes, I have the Fedora boot splash enabled. >> >>> > Once the console login shows up the screen is in some legacy >>> > low-res mode and Xorg can't be started. >>> > >>> > A git bisect between v5.14-rc3 (good) and v5.14-rc4 (bad) >>> > identified >>> > >>> > # first bad commit: [69de4421bb4c103ef42a32bafc596e23918c106f] >>> > drm/ttm: Initialize debugfs from ttm_global_init() >>> > >>> > Reverting that from 5.14.0-rc4 gives me a working kernel again. >>> > >>> > Note that I have # CONFIG_DEBUG_FS is not set >>> >>> That all matches here, including the unset CONFIG_DEBUG_FS and >>> confirming the revert on 5.14.0-rc4 works. >> >> Thanks for the confirmation. > > 69de44d1bb introduced a regression in rc4, reported to the list on > August 2, that's still there in rc6. It's also reported on kernel > bugzilla as bug #214000. No maintainer response either on-list or to > the bug. The commit was general ttm and the original post went to > dri-devel and kernel, > Jason E. and Daniel V., but all three user reports I've seen so far > (two on-list and the bug reporter) are on amdgpu or radeon, so in an > effort to at least get a response and hopefully a fix before release, > I'm adding the amdgpu/radeon list and maintainers. > > The bugzilla report confirmed that CONFIG_DEBUG_FS=y AND > CONFIG_DEBUG_FS_ALLOW_ALL=y were *both* required to get a working > kernel after that commit. I and I believe the on-list reporter just > reverted the commit in question, and kept our CONFIG_DEBUG_FS=n. Trying again. I apologize if anyone gets this twice but I don't think the first one made it at all (buggy client). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
