Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 16 Aug 2021 01:22:16 -0700
From:   Duncan <1i5t5.duncan@cox.net>
To:     amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        Jason Ekstrand <jason@jlekstrand.net>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Alex Deucher <alexander.deucher@amd.com>,
        Christian =?UTF-8?B?S8O2bmln?= <christian.koenig@amd.com>,
        Pan Xinhui <Xinhui.Pan@amd.com>,
        Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION][BISECTED] 5.14.0-rc4 thru rc6 69de4421bb broke
Message-ID: <20210816012216.47babaf6@ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@cox.net> wrote:
>>> Mikael Pettersson <mikpelinux@gmail.com> 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