Arch Linux

You will need to provide more information...

Please attach dmesg output from working and non-working versions.

Attached are as follows:

linux41-full: full dmesg output on linux 4.1.6-1
linux41-acpi: dmesg piped into grep on linux 4.1.6-1 (grep -i acpi)
linux42-full: full dmesg output on linux 4.2.1-1
linux42-acpi: dmesg piped into grep on linux 4.2.1-1 (grep -i acpi)

Issue still present in 4.4.3-1. Appeared in one of the more recent linux-lts releases.

I have had a similar issue on a Dell Inspiron 14 7437. I solved this by building my own kernel using ABS and adding 'CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y' to my .config.

I also had to add 'acpi_rev_override' as a kernel command line argument. I do not have a full understanding on how this changes how the kernel interacts with the hardware, but it seems to work so I am happy with that. This thread is originally what pointed me in the right direction http://ubuntuforums.org/archive/index.php/t-2308941.html.

I have attached my current .config to this post. Although I only made a change to the CONFIG_ACPI_REV_OVERRIDE_POSSIBLE line.

Let me know if you need any other details.

It looks like Ubuntu has that compiled in their generic kernel, could this be included in Arch's?

Also thanks, I assume this will work on my 7537 and this has been bugging me for some time now (especially since linux-lts has the same problem now).

This could very easily be implemented into the arch kernel, however that is up to the arch devs. As a workaround have a look at the wiki page on using abs to build your own arch kernel.

I'm very aware of how to use the abs and how to build my own packages. I only made a suggestion that it be put in the ARCH kernel.

A new problem comes up when using this that the wireless card becomes disabled when you unplug the AC cable and requires a restart in order for that to come back on when acpi_rev_override is used. Perhaps there's another solution.

I have not experienced issues with the wifi card disabling. But have had issues with bluetooth. I found that the issue was caused by the systemd service "systemd-modules-load.service" which was not loading. The message returned from this service was "Failed to find module 'acpi_call'". After installing acpi_call from the community repository, this issue was resolved. I am unsure if this will work in your case, however it may be worth a try.

systemd-modules-load.service loads with no problems. Then when I install acpi_call, the unit fails and there is no effect on the problem.

is this issue still valid?

Yes.

is it valid with latest kernel?

It appears no actually, but it did sometimes magically work just fine on some boots. I'll watch the next few boots to see if it continues to work.