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
