[SOLVED] problems with acpi irq, boot freezes

tux01 · 06-17-2021, 04:35 AM

Hi,I am trying to install Gentoo onto two different laptops (Lenovo and HP), both with Intel CPU and integrated graphics. The problem is that the boot hangs forever as early as at boot runlevel (I use openRC as init). I tried to search for parameters to add at the GRUB kernel boot line and found out that only "acpi=noirq" AND "noapic" work. So I assume that this is a problem with ACPI and interrupts. However 1) this only happens with Gentoo, other distros boot normally, 2) it doesn't really fix the issue and 3) I don't really know if keeping these parameters is harmless for my hardware in the long run.
Here is the ACPI section of my kernel configuration (I have left everything as recommended by Gentoo wiki):

Code:

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_HIBERNATION_SNAPSHOT_DEV=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_AUTOSLEEP=y
CONFIG_PM_WAKELOCKS=y
CONFIG_PM_WAKELOCKS_LIMIT=100
CONFIG_PM_WAKELOCKS_GC=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_CLK=y
CONFIG_PM_GENERIC_DOMAINS=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_PM_GENERIC_DOMAINS_SLEEP=y
CONFIG_ENERGY_MODEL=y
CONFIG_ARCH_SUPPORTS_ACPI=y
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SPCR_TABLE=y
CONFIG_ACPI_LPIT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_TINY_POWER_BUTTON=m
CONFIG_ACPI_TINY_POWER_BUTTON_SIGNAL=38
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_TAD=m
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_BGRT=y
CONFIG_ACPI_NFIT=m
# CONFIG_NFIT_SECURITY_DEBUG is not set
CONFIG_ACPI_NUMA=y
CONFIG_ACPI_HMAT=y
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
# CONFIG_ACPI_APEI_EINJ is not set
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
CONFIG_ACPI_DPTF=y
CONFIG_DPTF_POWER=m
CONFIG_DPTF_PCH_FIVR=m
CONFIG_ACPI_WATCHDOG=y
CONFIG_ACPI_EXTLOG=m
CONFIG_ACPI_ADXL=y
CONFIG_ACPI_CONFIGFS=m
CONFIG_PMIC_OPREGION=y
# CONFIG_XPOWER_PMIC_OPREGION is not set
# CONFIG_BXT_WC_PMIC_OPREGION is not set
CONFIG_CHT_DC_TI_PMIC_OPREGION=y
CONFIG_X86_PM_TIMER=y
CONFIG_SFI=y

business_kid · 06-17-2021, 01:24 PM

'Early in the boot' isn't really good enough. In the early stages

The PC comes on , stretches itself does POST, and throws up grub
The kernel boots next, finds basic hardware, mounts / and loads init
init finds all the peripherals, etc.

That's the abbreviated version, as it's more complicated but they are the main stages you see.

ACPI or acpid is a daemon started in the init stage. the apic is a programmable interrupt controller, so don't confuse them. Which stage do you get trouble in?

tux01 · 06-17-2021, 04:35 PM

After openRC completes the sysint runlevel and enters the boot runlevel the process hangs forever. Because I have to add both parameters (noapic and apci=noirq) to the kernel in order to boot normally, it means that 1) ACPI is not able to handle IRQ routing (apci=noirq) and 2) the system can only look for the $PIR table to get the interrupt routing information. However I don't really have an explanation as to why this occurs...it never happened with any other distro.

business_kid · 06-18-2021, 08:00 AM

ACPI is a software daemon; it's hardware that needs interrupts, unless you're talking about software interrupts. I think the days when 'acpi=noirq' would be of much assistance are gone, although there remain some kernel quirks for buggy portions of ACPI.

ACPI reacts to acpi events, and these can be linked to acpi actions. The way to get a handle on this behaviour is as follows. One laptop at a time, stop acpid, then run it as 'acpid -l. That logs events. Put a 'tail -f <file>' command on that, which should you seeing the events on the new log lines. Closing the lid is an acpi event, but if you open it quickly, nothing is done. But that should be logged as an acpi event. You can then link events to scripts, or configure whatever power manager your particular window manager has. Go through setting it up once, then don't fix it!

tux01 · 06-19-2021, 12:51 PM

Thanks for your suggestion and explanation, unfortunately I carefully inspected the rc.log and messages files in /var/log,but acpid did not log any error. My guess is that there is something wrong between BIOS and the kernel, but I have been using the same kernel branches with other distros and they all worked fine. BTW, the BIOS is up to date and I have found out that passing my parameters to the kernel line at boot won't get my touchpad working, so the workaround is not valid anymore.

business_kid · 06-19-2021, 01:49 PM

There's not enough detail there for me to make much sense of the situation. I don't even know if you found the log where a lid closure was recorded. "Other distros work" appears to be your solution. If other distros work, use them. I don't know why you're using OpenRC, but this would be a good time to eliminate that as a possible cause. To faultfind the situation remotely, readers of your posts need to know the facts, with relevant pastes.

tux01 · 06-20-2021, 10:45 AM

In the end I think that the kernel is the real culprit. I tried to downgrade it to an old LTS build and it works for now, so I should be waiting for the packagers to fix the new version. Marking as (half-)solved.