From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [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
Date: Fri, 13 Aug 2021 18:24:12 +0000 [thread overview]
Message-ID: <bug-214001-2300-5cxax72eI0@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-214001-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=214001
--- Comment #3 from Linux_Chemist (untaintableangel@hotmail.co.uk) ---
Thanks for your comment, Duncan!
Yes, I'm on a customised kernel that has a lot removed (including debugfs as
you can tell) and also amdgpu (RX 5700).
There's usually a bug in a testing RC every few releases, I just report them
here after bisecting; seems the right place for it even if it's not lol
Caught a nice bug last release cycle with the memory reservation for the bios
(https://www.phoronix.com/scan.php?page=news_item&px=Linux-Always-Reserve-1MB)
(I wasn't sure to file this one under an AMD ("non-intel") specific 'video' bug
but the commit was for 'drivers/gpu/drm/ttm' which I assume is agnostic. I
don't know what it's for or whether only amdgpu/radeon makes use of it to say
but it is interesting that the 3 of us have similar hardware.)
I can confirm all my .configs have had CONFIG_VGA_CONSOLE=y in it (though a lot
of fallback stuff pulled out that probably stops me getting the legacy low-res
VGA mode you mention, c'est la vie)
But anyways as you say, the ability to create a bootable kernel only becomes an
issue from the commit in question when not having CONFIG_DEBUG_FS=y (and
CONFIG_DEBUG_FS_ALLOW_ALL=y along with that)
Don't get me wrong, it's not a showstopper 'massive bug' because you can always
put debugfs + 'allow all' into your kernel, I did so and am happily on rc5 now,
but that's why I'd like a consensus to be known or shared (i.e. change the
wording for the kconfig options) about whether a lot of things are expecting
debugfs to be there in some form now - is it now an 'essential' part of the
kernel? Or should things that rely on it fail gracefully if they don't find it?
Either it's essential and this isn't a bug and there needs to be clarification
that debugfs should always be there in some form, or this is a bug and the
commit needs tweaked to account for debugfs not being there or there in a
diminished capacity.
It is a bit silly that even CONFIG_DEBUG_FS_ALLOW_NONE wouldn't work for this
bug because that seems like it should be providing that 'fail gracefully'
mechanism to debugfs being 'there' but 'don't bother with it'.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2021-08-13 18:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-08 19:09 [Bug 214001] New: [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
2021-08-08 19:09 ` [Bug 214001] " bugzilla-daemon
2021-08-08 19:18 ` bugzilla-daemon
2021-08-09 11:09 ` bugzilla-daemon
2021-08-13 17:50 ` bugzilla-daemon
2021-08-13 18:24 ` bugzilla-daemon [this message]
2021-08-13 19:59 ` bugzilla-daemon
2021-08-22 22:10 ` bugzilla-daemon
2021-08-22 22:19 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-214001-2300-5cxax72eI0@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.