Thanks for the insight ! I still wonder why the 'acpi=on' helped on the one machine. Because it made a difference, I assume the 'acpi=on' is a different value than the compiled-in default.
I tried to look up what the default is. I looked here: https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config and here: grep CONFIG_ACPI /boot/config-$(uname -r) but I think the 'CONFIG_ACPI=y' just means that the support for the ACPI is enabled when the kernel is compiled, but it does not say what the actual used default value is. How do I find the actually used value, when I do not specify it on the kernel command line? Michal -- Michal Schorm Software Engineer Databases Team Red Hat -- On Tue, Jun 3, 2025 at 11:51 AM Hans de Goede <hdego...@redhat.com> wrote: > > Hi Michal, > > On 3-Jun-25 11:35 AM, Michal Schorm wrote: > > On Mon, Jun 2, 2025 at 4:09 PM Hans de Goede <hdego...@redhat.com> wrote: > >> I'm not sure why you are specifying apci=off in the first place? > > > > On the system where I started, I met some ACPI related errors in the > > kernel ring buffer. > > Firmware ACPI tables often contain bugs which the parser will complain > about. Typically these ACPI functions also do not work under Windows > (for which the laptop was typically designed / QE-ed with) but them > failing to execute properly is not a problem in real life. > > IOW typically it is safe to just ignore ACPI errors in dmesg and > ignoring them is much better then fully disabling ACPI. > > Even if the errors are real they usually only cause a single device / > function to stop working where as acpi=off just breaks everything. > > > Disabling the problematic functionality often works as a good starting > > ground for me when debugging. > > Normally I would agree but on modern HW everything pretty much depends > on ACPI. Most hw relies on ACPI to be turned on/off by the kernel > properly and some hw can only be discovered through its ACPI description. > > >> Most modern (even old modern) systems all need ACPI for various reasons. > > > > Sure. When I disable kernel functionality, I expect some system > > functionality to be missing. > > > > However - and that is my main point - I also expect it to be > > traceable, so I would be able to tell from the running system that > > something does not work because of this missing functionality. > > ACPI described hardware (and offers functions to do things mostly > turn on/off with that hw). If you disable ACPI then the kernel does > not know it is missing power-management support, or outright is > not finding various devices like e.g. i2c-controllers + attached > touchpads / touchscreens, because you took away the description > telling the kernel it should have those things. > > ACPI is such an integral part of all x86_64 systems that disabling it > just is a really really bad idea. The whole option to disable ACPI > stems from its beginning days when it was just replacing APM > (around 2000) and there still were serious issues with it *and* > disabling it did not cause so much issues since it was not widely > used yet. > > >> Generally speaking passing any extra kernel command line options other > >> then the default "root=... ro rhgb quiet" is a bad idea unless you have > >> a very specific reason for doing this; or were asked to try a kernel > >> cmdline option by a kernel-developer while debugging some option. > > > > In theory? Maybe. In practice, hardly. :) > > As an upstream kernel maintainer I disagree. Yes sometimes there > are bugs, but we do our best to fix those and often people are using > kernel cmdline options because they read some ancient forum post and > they do not need the options at all and often these options do more > harm then good. I have helped quite a large number of users just by > telling them to remove some special options. > > <snip> > > > The main reason why I write to the devel@ list, instead of the users@ > > list is the question I opened - is it expected that 'acpi=off' would > > break all BIOS installation (but not UEFI) in the same way? > > acpi=off nowadays pretty much is expected to break a whole lot of stuff, > including systems just being able to boot. This is independent of BIOS vs > UEFI, if you've seen it work better on UEFI systems that might be because > the firmware does a little more hw initialization itself before starting > the kernel, but I would mostly chalk it down to luck. > > Regards, > > Hans > > > > > > > On Mon, Jun 2, 2025 at 4:09 PM Hans de Goede <hdego...@redhat.com> wrote: > >> > >> Hi Michal, > >> > >> On 2-Jun-25 15:28, Michal Schorm wrote: > >>> I maintain a fleet of very old 64-bit laptops in various conditions > >>> for events for youth. > >>> I use a set of custom installation and configuration scripts to > >>> install Fedora + Cinnamon DE. > >>> > >>> When debugging an issue on two machines, I discovered that using > >>> 'acpi=off' as a kernel parameter breaks every BIOS installation I > >>> have, and some UEFI too. > >>> > >>> Some UEFI installations just have low resolution, or respond noticeably > >>> slower. > >>> Some UEFI and some BIOS installations freeze somewhere during the boot > >>> sequence. (haven´t examined more closely) > >>> > >>> And most of the BIOS installations boot, but fail to display the GUI. > >>> The TTY1 ends in some non-interactive state, but not frozen (still can > >>> display incoming systemd journal messages etc.). I can switch to other > >>> TTYs, where there is a TUI login prompt and the system is normally > >>> accessible from there. > >>> > >>> I carefully examined the kernel messages and systemd journal, both > >>> with extra verbosity levels. > >>> Nothing seems wrong there. The multi-user.target was reached, all > >>> services are fine, none related errors or unusual warnings, all > >>> necessary packages seem to be installed, ... > >>> > >>> My first question is whether it is expected that 'acpi=off' will > >>> prevent the BIOS installations from displaying GUI. Or if any of you > >>> can reproduce at all. > >>> > >>> My second question is how to further debug and where to look. > >>> Most of the BIOS systems work completely normal when 'acpi=off' is NOT > >>> specified. > >>> I fixed one machine by setting 'acpi=on' (which leads to a different > >>> result than not specifying the acpi kernel option value at all) and I > >>> have one machine that shows the exact same symptom, but the cause > >>> doesn't seem to be 'acpi=...' related, as any possible value won't > >>> help. > >> > >> I'm not sure why you are specifying apci=off in the first place? > >> > >> Most modern (even old modern) systems all need ACPI for various reasons. > >> > >> Generally speaking passing any extra kernel commandline options other > >> then the default "root=... ro rhgb quiet" is a bad idea unless you have > >> a very specific reason for doing this; or were asked to try a kernel > >> cmdline option by a kernel-developer while debugging some option. > >> > >> As for acpi=on helping, "on" is not a valid value for acpi="val", > >> so that likely is some false positive related to no longer specifying > >> acpi=off. > >> > >> TL;DR: do not use acpi=off, actually do not use any special kernel > >> commandline arguments at all. > >> > >> Regards, > >> > >> Hans > >> > > > -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
