[Bug 214001] [bisected][regression] After commit "drm/ttm: Initialize debugfs from ttm_global_init()" kernels without debugfs explicitly set to 'allow all' fail to boot

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Fri Aug 13 17:50:29 UTC 2021


https://bugzilla.kernel.org/show_bug.cgi?id=214001

Duncan (1i5t5.duncan at cox.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |1i5t5.duncan at cox.net

--- Comment #2 from Duncan (1i5t5.duncan at cox.net) ---
This has been reported (by someone else) on the dri-devel list (with the main
kernel list and the devs CCed) as well, with me confirming it there.  No answer
from the devs there either.  The reporter and I followed reporting instructions
to take it to the list, and no hint it was even seen, despite the release
getting closer and closer.

So I was going to try bugzilla (despite instructions to take it to the list),
to see if I could raise the profile a bit, and find this bug.

Anyway, it's on both channels now.  FWIW:

https://lore.kernel.org/dri-devel/?q=5.14.0-rc4+broke+drm%2Fttm

Tho FWIW your symptoms are a bit different than those of the OP there and I. 
We were able to boot, but only to legacy low-res VGA mode.  He has a
boot-splash enabled and the screen blanked from early boot when the
drm-framebuffer would normally take over until the login prompt, which appeared
in vga mode.  I prefer to see the boot messages so no splash, and didn't have
it blank, the screen just never left the legacy vga mode it normally uses for
early boot.  We're both on Radeons; he's on the old radeon driver while I'm on
amdgpu (polaris-11, rx460).

I wonder if you don't have the legacy vgacon (CONFIG_VGA_CONSOLE) enabled as a
fall-back, as that would explain an apparent hang due to no valid graphics (tho
the system may have booted, just without graphics).  Alternatively, I don't
know what the behavior of non-radeon/amdgpu drm-framebuffer drivers is, maybe
whatever you're running either does hang or simply doesn't fall back to vgacon
as our radeon and amdgpu drivers did?

But in both his case and mine it bisected to the same commit, 69de4421bb, and
reverting it against current gave both of us working systems again, so it's the
same bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.


More information about the dri-devel mailing list