[BISECTED] 5.14.0-rc4 broke drm/ttm when !CONFIG_DEBUG_FS

[BISECTED] 5.14.0-rc4 broke drm/ttm when !CONFIG_DEBUG_FS

[Mikael Pettersson]

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

after which the screen goes black for the rest of kernel boot and
early user-space init.
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

/Mikael

Re: [BISECTED] 5.14.0-rc4 broke drm/ttm when !CONFIG_DEBUG_FS

[Duncan]

[Not subscribed so please CC me.  Manual quoting after using lore's
in-reply-to functionality.  First time doing that so hope I got it
right.]

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.

> 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.

-- 
Duncan - HTML messages treated as spam
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
Benjamin Franklin

Re: [BISECTED] 5.14.0-rc4 broke drm/ttm when !CONFIG_DEBUG_FS

[Mikael Pettersson]

On Mon, Aug 2, 2021 at 8:29 PM Duncan <j.duncan@cox.net> wrote:
>
> [Not subscribed so please CC me.  Manual quoting after using lore's
> in-reply-to functionality.  First time doing that so hope I got it
> right.]
>
> 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.

Re: [PATCH] drm/ttm: allow debugfs_create_file() to fail in ttm_global_init()

[Duncan]

On Mon, 16 Aug 2021 16:30:46 +0200
lnx7586@gregdf.com wrote:

> From: Greg Depoire--Ferrer <lnx7586@gregdf.com>
> 
> Commit 69de4421bb4c ("drm/ttm: Initialize debugfs from
> ttm_global_init()") unintentionally made ttm_global_init() return
> early with an error when debugfs_create_file() fails. When
> CONFIG_DEBUG_FS is disabled, debugfs_create_file() returns a ENODEV
> error so the TTM device would fail to initialize.
> 
> Instead of returning early with the error, print it and continue.
> ENODEV can be ignored because it just means that CONFIG_DEBUG_FS is
> disabled.
> 
> Fixes: 69de4421bb4c ("drm/ttm: Initialize debugfs from ttm_global_init()")
> Reported-by: Mikael Pettersson <mikpelinux@gmail.com>
> Reported-by: Duncan <j.duncan@cox.net>
> Signed-off-by: Greg Depoire--Ferrer <lnx7586@gregdf.com>
> ---
> Hi, I had this bug as well with the nouveau driver after updating.
> This patch fixes it for me.
> 
>  drivers/gpu/drm/ttm/ttm_device.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)

This fixes the problem here, too.  Running it now.

Tested-by: Duncan <j.duncan@cox.net>

-- 
Duncan - HTML messages treated as spam
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
Benjamin Franklin