[HP ProBook 450 G1 Notebook PC] Wireless switch not working

This change was made by a bot.

Hi Christopher, thanks for your support. I just tried the AMD64 ISO image of the daily snapshot of 14.04 from the links you provided. The behaviour is the exact same one of 13.10 (i.e.: button not working, same message in dmesg, orange led even when WiFi is enabled).

Mauro, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.15-rc2

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Hi Christopher, I will surely try as soon as I have some spare time. Anyway, may I ask you if I can install a mainline kernel build on the USB I created with the daily snapshot of Trusty (said that I've reserved 1 GB space for persistent data when I have created the USB stick with the usb-creator)? Or must I try this on an *installed* instance of Ubuntu? In the latter case, I think I'll have to do it on my Mint 16 installation, since I do not have an installed instance of Ubuntu (and I don't have a spare hard drive to prepare one).

Kernel parameter to workaround this bug on an HP EliteBook 840 G1: acpi_osi='!Windows 2012'

Alternative solution that worked for me on Linux 3.14.4, too: CONFIG_HP_WIRELESS=y

Related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1303420

Steffen, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Sorry, I'm not an Ubuntu user. Just wanted to let you know about possible solutions.

I confirm acpi_osi='!Windows 2012' kernel boot parameter works for me, too (on an HP ProBook 450 G1), with Linux Mint 16 KDE (based on Ubuntu 13.10). I notice that there's a difference in "rfkill list" output with and without this kernel boot parameter:

- without it:
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

- with it:
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hp-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: hp-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
4: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

So, there are two new entries, hp-wifi and hp-bluetooth. When I press the switch to deactivate the wifi, the "hard blocked" for phy0 and hp-wifi turns to "yes" (I can't remember if it turns to yes even for the other two bluetooth entries).

Which other side effects may I have by using this kernel boot parameter?

Steffen, where should I put CONFIG_HP_WIRELESS=y? Is it meant to be a kernel boot parameter too? It seems to be more specific compared to acpi_osi...

Cristopher: I didn't forget your request. I'm going to try a newer kernel as soon as I have some spare time.

CONFIG_HP_WIRELESS=y is a Linux kernel configuration option that is available since Linux 3.14. You have to compile a new kernel unless Ubuntu decides to backport this feature (IIRC Ubuntu 14.04 uses Linux 3.13).

I see, thanks Steffen for your explanation.

I did some better tests. With acpi_osi='!Windows 2012' and the default 3.11.0-12-generic kernel, when I deactivate wifi using the switch button I get the following output:

0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hp-wifi: Wireless LAN
        Soft blocked: no
        Hard blocked: yes
2: hp-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: yes

That is: the phy0 entry is not blocked (sorry for the wrong information i gave previously), but the hp-bluetooh entry appears as hard blocked, while the hci0 has gone completely.

This said, I tested the following mainline kernel versions (without using acpi_osi='!Windows 2012') as suggested by Christopher. I did these tests directly on my Linux Mint 16 KDE installation, because installing a mainline kernel version on the live USB stick of Ubuntu 14.04 did not work. Here are the results:
- with 3.12-rc7-saucy (the latest one built specifically for Saucy, which Mint 16 is based on) the problem is still present (the wireless witch button does not work)
- with 3.15-rc2-trusty (the latest one built specifically for Trusty) the problem is fixed (the wireless switch button does work)

However, with 3.15-rc2 without the acpi_osi='!Windows 2012' boot parameter, the output of "rfkill list" is:
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
and when the wifi is disabled it is:
0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: yes
        Hard blocked: no

That is: the hp-wifi and hp-bluetooth entries are missing and the switch causes a soft-block rather than a hard block. I would say the most correct behaviour is the one I have with acpi_osi='!Windows 2012' (i.e.: the system sees the hp-* entries and the button performs a hard block), but I'm not an expert. After all, the final result from a user point of view is the same (the button works and the led on it reflects the current enabling state of the wifi card).

I still don't know what acpi_osi='!Windows 2012' is really meant to be and whether there may be any other side effects when using it.

Hi Christopher,
I switched the bug status to Confirmed because you had told me to do that. Why Incomplete again, then? What should I do now?

Mauro, the next step would be to fully reverse commit bisect in order to identify the fix commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Hi Christopher, I will try to do my best.

First of all, what about my considerations on the acpi_osi kernel boot parameter?

Secondly, I did a "binary search" of the first mainline kernel version which works. The result is not so linear. I'll explain.

Version 3.11.2 (package name mentions 3.13.11-03131102.201405081435) still has the problem

From 3.14-rc1 onwards, the problem is fixed. However... with 3.14-rc1, 3.14-rc2 and 3.14-rc3 if I type:
sudo rfkill list
I see an output which is similar to what I get if I specify the acpi_osi boot parameter with 3.11 kernel, that is I get the hp-wifi and hp-bluetooth entries and the switch applies a hard block rather than a soft block. The only difference is that the hci0 does not disappear when the wifi card is disabled.
From 3.14-rc4 onwards, the problem is still fixed, but if I type rfkill list, I see the output that I get with 3.15-rc2, that is without the hp-* entries. Also, the wifi switch button produces a soft block instead of a hard block.

This makes me think that there are at least two commits (one for 3.14-rc1 and one for 3.14-rc4) that in some way have effects on this.
Any suggestion?

bug 1303737 should be fixed by commit 15d75fcebdf78d316a980487eddcac8e4f1574c8, which is in Trusty as of Ubuntu-3.13.0-28.51. This commit is a cherry pick of upstream 54290fa6.

Can you test the 3.13.0-28.51 kernel and confirm if it fixes this bug or not? It can be downloaded from:
https://launchpad.net/~canonical-kernel-team/+archive/ppa/+files/linux-image-3.13.0-28-generic_3.13.0-28.51_amd64.deb

Hi Joseph,
unfortunately with that kernel image I can't boot: after choosing it in the GRUB boot menu, the screen stays blank and the password prompt for dm-crypt does not show. If I choose the corresponding "recovery mode" entry, I get to a screen with messy and corrupted graphics. I can't do anything than ctrl+alt+canc and choose another boot entry.

After installing also https://launchpad.net/~canonical-kernel-team/+archive/ppa/+files/linux-image-extra-3.13.0-28-generic_3.13.0-28.51_amd64.deb (as suggested by Jonathan here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1303420/comments/21) I can boot with this kernel image. The wifi switch works just like in 3.14-rc4+ (i.e.: it performs a soft block, rfkill list shows no hp-* entries).

Had that issue also. Just installed the Linux subi 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux kernel from the 14.04 repos and now the buttons works.

In Kubuntu when I press the button it turns "yellowish" and KDE Network Manager shows Wifi as disabled. When I press it again, Wifi becomes enabled again (the card).

As stated here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1303737/comments/12
I verified this is fixed in Linux Mint KDE 16 and Ubuntu 13.10 by installing the kernel package version 3.11.0-24.41.
Thanks!

This change was made by a bot.

The wireless switch worked perfectly in Linux Mint 16 KDE (based on Ubuntu 13.10) with kernel version 3.11.0-24.41: toggling the wifi on/off worked and the led on the button was correctly white when on and orange when off.

However, in Linux Mint 17 KDE (based on Ubuntu 14.04) with kernel version 3.13.0-36.63 it has a little problem: toggling wifi on and off works, but the led on the button always stays orange, even when the wifi is active.

So, there's a little regression here.

Today I tried http://cdimage.ubuntu.com/daily-live/current/vivid-desktop-amd64.iso.
A regression with the wireless switch state is there too.
With that image, the wireless switch is always white, disregarding the wireless card activation state (enabled or disabled).
Toggling works, however (it always produces a soft block).

In summary:
- with 13.10 and kernel version 3.11.0-24.41 the button works perfectly (toggling works, white led colour for enabled, orange for disabled), apart from the fact that it causes a soft block rather than a hard block (but maybe this is the desired behaviour)
- with 14.04 and kernel version 3.13.0-36.63 wifi toggling works, but most of the times the led says orange even when wifi is enabled (it doesn't happen always, but often... I still haven't understood when it happens, it seems randomly)
- with 15.04 from the daily live wifi toggling works, but the led stays always white, even when the wifi is disabled

Still, with kernel version 4.4.0-47-generic #68~14.04.1-Ubuntu, the wireless switch does enable and disable the wifi card (with a soft block), but the led remains white in any case (while it should turn orange when the wifi card is disabled).

I don't know if it's relevant, but even if I add "acpi_osi=Linux" kernel boot parameter (necessary to make resume from hibernate work, see bug #1701081), the behaviour of the wifi switch is the same.

Mauro,

Try latest mainline kernel here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc7/

Sorry, I must correct myself! With kernel 4.4.0-47-generic #68~14.04.1-Ubuntu the wireless switch button correctly turns orange when the wifi card is disabled, so this bug is completely fixed.

When I tested this in June I was cheated by the fact that the led turns orange after some seconds, rather than immediately.

So, from my point of view, this bug is completely fixed with recent kernel versions. I also verified it's fixed with 4.13-rc1 mainline kernel.

I think this can be closed :-)

Writing this from a WiFi network... and my LED is orange. (4.10.0-28-generic)