There are two different types of problems. On one hand, the ACPI code of the kernel may contain bugs that were not detected in time. In this case, a solution will be made available for download.
More often, however, the problems are caused by the BIOS. Sometimes, deviations from the ACPI specification are purposely integrated in the BIOS to circumvent errors in the ACPI implementation
in other widespread operating systems. Hardware components that have serious errors in the ACPI implementation are recorded in a blacklist that prevents the Linux kernel from using ACPI for these components.
The first thing to do when problems are encountered is to update the BIOS. If the computer does not boot at all, one of the following boot parameters may be helpful:
pci=noacpi
Do not use ACPI for configuring the PCI devices.
acpi=ht
Only perform a simple resource configuration. Do not use ACPI for other purposes.
acpi=off
Disable ACPI.
WARNING: Problems Booting without ACPI
Some newer machines (especially SMP systems and AMD64 systems) need ACPI for configuring the hardware correctly. On these machines, disabling ACPI can cause problems.
Monitor the boot messages of the system with the command dmesg | grep -2i acpi (or all messages, because the problem may not be caused by ACPI) after booting.
If an error occurs while parsing an ACPI table, the most important table—the DSDT—can be replaced with an improved version. In this case, the faulty DSDT of the BIOS is ignored. The procedure is described in Section 28.5.4, Troubleshooting.
In the kernel configuration, there is a switch for activating ACPI debug messages. If a kernel with ACPI debugging is compiled and installed, experts searching for an error can be supported with detailed information.
If you experience BIOS or hardware problems, it is always advisable to contact the manufacturers. Especially if they do not always provide assistance for Linux, they should be confronted with the problems.
Manufacturers will only take the issue seriously if they realize that an adequate number of their customers use Linux.
I took a look of that information, but it is from SLES10 and I do not have the path /proc/acpi. My OpenSuse is Leap 42.1 with systemd and the paths that I have related to acpi are: /lib/modules/4.1.15-8-default/kernel/drivers/acpi, /sys/module/acpi and /sys/module/acpi/parameters. I read the Troubleshooting section and I set the following debug options:
Hi,
have you fixed the problem?
I’m having the same issues with a HP Envy 15 laptop.
The strange thing is that with Tumbleweed everything works fine but I’d like to go with Leap.
> x3m3;2792198 Wrote:
> > Hi,
> > have you fixed the problem?
> > I’m having the same issues with a HP Envy 15 laptop.
> > The strange thing is that with Tumbleweed everything works fine but I’d
> > like to go with Leap.
>
>
> Hi x3m3,
>
> I haven’t fixed the problem. Maybe we can see the issue if we run the
> kernel in debug mode.
>
>
Well, you could use Leap with a more recent kernel from one of these repos:
If your machine is running well with 4.4.X from (upcoming) 42.2 it would be my
first choice as it will stay a 4.4.X for some considerable time.
If you rely on external proprietary drivers (fglrx or nvidia come to mind) you
will have to take care of them yourself, but that is not too complicated if you
once know how to do that.
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
If I select NoACPI before starting the installation everything goes fine but many features are not installed.
in the next days I’ll find the time to make another attempt and upload the logfile.
In the meantime I’m enjoying Leap 42.1 on another laptop (acer) where installation has been smooth.