Hi Michal, On 3-Jun-25 12:51 PM, Michal Schorm wrote: > 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?
You can find all valid values for acpi=foo on x86 here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/acpi/boot.c#n1673 As you can see this sets various flags, the default of these flags is defined in the code and is typically 0. Regards, Hans > 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
