168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.4kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc1-precise/

Hi Joseph,
I installed the mainline kernel and I tested it.

uname -a
Linux cristian-Compaq-Presario-C700-Notebook-PC 3.4.0-030400rc1-generic #201203312035 SMP Sun Apr 1 00:43:10 UTC 2012 i686 i686 i386 GNU/Linux

Unfortunately, the bug continues to persist :(

I've changed tags as you have said. Let me know :)

cristian, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, 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-v3.13-rc3

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.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I've tested the latest development release (14.04 daily build) and this is still an issue.
I've also tested the latest upstream kernel (3.8.13-03081314) for my installed ubuntu release and this is still an issue.

cristian, thank you for your comments. Could you please test the latest mainline kernel available via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc5-trusty/ and advise to the results?

I've tested the 3.13.0-031300rc5 kernel and I noticed this bug getting worse compared to the previous kernels. Exactly, the switch between wifi on and off is very slow and the LED does not change color by pressing the button before or after performing the workaround.

cristian, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

Can you confirm this bug exists in the 3.14-rc5 kernel:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc5-trusty/

If the bugs still exists, I'll perform a bisect, so we can identify when it was introduced.

I've tried the 3.14-rc5 kernel:

uname -a
Linux cristian-Compaq-Presario-C700-Notebook-PC 3.14.0-031400rc5-generic #201403022235 SMP Mon Mar 3 03:56:52 UTC 2014 i686 i686 i686 GNU/Linux

I confirm the regressions also for this release.

To perform a bisect, we first need to identify the last good kernel and the first bad kernel.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

2.6.38 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.38-natty/
3.0-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-rc1-oneiric/
3.0 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-oneiric/

You don't have to test every kernel, just up until the kernel that first has this bug.

Ok, I've tested 2.6.38 and 3.0 final kernels (about 3.0-rc1 version, there aren't deb packages for i386 architecture).

Results for 2.6.38 final and 3.0 final are the same: no regressions but there is the original bug.
So:
wifi led button is blinking (red/blue), radio switch is regular (on/off fast). After the workaround, blinking stops, but colors are reversed for wifi on/off.

Can you report this upstream as suggested in comment #22, since this bug still happens with the latest mainline kernel?

I add more info about /sys/class/leds/ and triggers, as I was asked.

ls -l /sys/class/leds/
totale 0
lrwxrwxrwx 1 root root 0 mar 15 07:24 ath5k-phy0::rx -> ../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/ath5k-phy0::rx
lrwxrwxrwx 1 root root 0 mar 15 07:11 ath5k-phy0::tx -> ../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/ath5k-phy0::tx

ls -l /sys/class/leds/ath5k-phy0::rx/
totale 0
-rw-r--r-- 1 root root 4096 mar 15 07:28 brightness
lrwxrwxrwx 1 root root 0 mar 15 07:28 device -> ../../../0000:01:00.0
-r--r--r-- 1 root root 4096 mar 15 07:28 max_brightness
drwxr-xr-x 2 root root 0 mar 15 07:28 power
lrwxrwxrwx 1 root root 0 mar 15 07:11 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 mar 15 07:28 trigger
-rw-r--r-- 1 root root 4096 mar 15 07:11 uevent

ls -l /sys/class/leds/ath5k-phy0::tx/
totale 0
-rw-r--r-- 1 root root 4096 mar 15 07:29 brightness
lrwxrwxrwx 1 root root 0 mar 15 07:29 device -> ../../../0000:01:00.0
-r--r--r-- 1 root root 4096 mar 15 07:29 max_brightness
drwxr-xr-x 2 root root 0 mar 15 07:29 power
lrwxrwxrwx 1 root root 0 mar 15 07:11 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 mar 15 07:11 trigger
-rw-r--r-- 1 root root 4096 mar 15 07:11 uevent

cat /sys/class/leds/ath5k-phy0::rx/trigger
none AC-online cpu0 cpu1 BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid rfkill0 rfkill1 [phy0rx] phy0tx phy0assoc phy0radio

cat /sys/class/leds/ath5k-phy0::tx/trigger
none AC-online cpu0 cpu1 BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid rfkill0 rfkill1 phy0rx [phy0tx] phy0assoc phy0radio

After workaround:

ls -l /sys/class/leds/ath5k-phy0::rx/
totale 0
-rw-r--r-- 1 root root 4096 mar 15 07:28 brightness
lrwxrwxrwx 1 root root 0 mar 15 07:28 device -> ../../../0000:01:00.0
-r--r--r-- 1 root root 4096 mar 15 07:28 max_brightness
drwxr-xr-x 2 root root 0 mar 15 07:28 power
lrwxrwxrwx 1 root root 0 mar 15 07:11 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 mar 15 07:41 trigger
-rw-r--r-- 1 root root 4096 mar 15 07:11 uevent

ls -l /sys/class/leds/ath5k-phy0::tx/
totale 0
-rw-r--r-- 1 root root 4096 mar 15 07:29 brightness
lrwxrwxrwx 1 root root 0 mar 15 07:29 device -> ../../../0000:01:00.0
-r--r--r-- 1 root root 4096 mar 15 07:29 max_brightness
drwxr-xr-x 2 root root 0 mar 15 07:29 power
lrwxrwxrwx 1 root root 0 mar 15 07:11 subsystem -> ../../../../../../class/leds
-rw-r--r-- 1 root root 4096 mar 15 07:41 trigger
-rw-r--r-- 1 root root 4096 mar 15 07:11 uevent

cat /sys/class/leds/ath5k-phy0::rx/trigger
none AC-online cpu0 cpu1 BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid rfkill0 rfkill1 phy0rx phy0tx phy0assoc [phy0radio]

cat /sys/class/leds/ath5k-phy0::tx/trigger
[none] AC-online cpu0 cpu1 BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid rfkill0 rfkill1 phy0rx phy0tx phy0assoc phy0radio

uname -a
Linux cristian-Compaq-Presario-C700-Notebook-PC 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:25:33 UTC 2013 i686 i686 i686 GNU/Linux

@cristian -- as to your IRC questions (below) I would include the /proc information we asked for above, and for the "any other" information a link to this bug which has the full logs on it (ie the URL at the top of this page).

  11:06:37 cristian_c | I've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
  11:07:04 cristian_c | I've read it, but I've got some doubts yet. for example: [7.7.] Other information that might be relevant to the problem
                            | (please look in /proc and include all information that you think to be relevant): While booted into the newest upstream
                            | mainline kernel only, execute the following via a terminal, and paste the results
  11:07:19 cristian_c | what information from /proc can I add to the upstream bug report?
  11:07:34 cristian_c | and then: [X.] Other notes, patches, fixes, workarounds: Please provide a link to your Launchpad bug report
  11:07:53 cristian_c | What exactly can I do about this specific point? Any ideas?

Some notest from IRC:

<cristian_c> jsalisbury, I can tell more: I notice that in 3.19rc6 and 3.19 stable now, and also in 3.13.0rc2 and rc3, I see in rfkill list the lack of hp-wifi interface
<cristian_c> jsalisbury, but there is only phy0
<cristian_c> jsalisbury, if for example immeditely after login I type: dmesg | tail in a terminal, I get a (back)trace
<cristian_c> simlar to a crash/kernel panic / etc...
<cristian_c> now, i try again with 3.19 stable
<jsalisbury> cristian_c, and 3.13-rc1 does not exhibit this?
<cristian_c> jsalisbury, 3.13.0rc2 and 3.13.0rc3 have also only phy0 in rfkill list output
<cristian_c> jsalisbury, I know that rc1 has got phy0 and hp-wifi interfaces, but I boot now in rc1 also
<jsalisbury> cristian_c, great, we may now be getting somewhere :-)
<cristian_c> jsalisbury, ok, tried now, 3.19 the same as 3.19rc6, trace with ioctl lines
<cristian_c> and phy0 only
<cristian_c> now, I try again with 3.13.0rc1
<jsalisbury> great
* jodh has quit (Quit: WeeChat 1.1.1)
<cristian_c> jsalisbury, ok, 3.13.rc1 tried now
<cristian_c> jsalisbury, dmesg | tail does not show trace
<cristian_c> and there are both hp-wifi and phy0 interfaces in rfkill list output
<jsalisbury> cristian_c, great, so I think we should bisect between 3.13-rc1 and 3.13-rc2. I'll start the bisect and build the first test kernel.
<cristian_c> jsalisbury, now, I test again the original bug and the regression in rc1
<cristian_c> jsalisbury, ok

I started a kernel bisect between v3.13-rc1 and v3.13-rc2. The kernel bisect will require testing of about 7-10 test kernels.

I built the first test kernel, up to the following commit:
dad337501d490b26fbf8d83baee99c788461c61c

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Commit dad337501d490b26fbf8d83baee99c788461c61c is bad.

I built the next test kernel, up to the following commit:
4c1cc40a2d49500d84038ff751bc6cd183e729b5

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the second test kernel and the results are very similar to the first test kernel: rfkill list output shows only phy0 interface, no (back)traces in dmesg | tail output. If I press the wifi switch button, network manager applet doesn't show any changes (no changes for rfkill list output too), but there is a low wifi led activity yet. If I execute the workaround, network manager applet doesn't show any changes again (no changes also for rfkill list output), but wifi led activity is interrupted (as expected).

I built the next test kernel, up to the following commit:
ab827fb399b453bd7d4a49e8878bc5f7018507dd

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the third test kernel (3.11.0?) and results are similar to 3.8.0 and 3.13-rc1. There are both hp-wifi and phy0 interfaces in rfkill list output, but there is also a (back)trace in dmesg | tail output. Wifi led is always blinking if the wifi switch is turned on. If I execute the workaround, colors are reversed as described at the top of this report.

I built the next test kernel, up to the following commit:
cab6661344f14a09d7aecdf821a40f68ef9b18cc

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the fourth test kernel and results are: rfkill list output shows only phy0 interface and dmesg | tail output shows a (back)trace. If I press the wifi switch button, network manager applet doesn't show any changes (no changes for rfkill list output too), but there is a low wifi led activity yet. If I execute the workaround, network manager applet doesn't show any changes again (no changes also for rfkill list output), but wifi led activity is interrupted (as expected).

I built the next test kernel, up to the following commit:
ed1128989ab242f44664b446702a512e5695c4b7

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the fifth test kernel and results are like for the third test kernel: there are both hp-wifi and phy0 interfaces in rfkill list output, there is a (back)trace in dmesg | tail output. Wifi led is always blinking if the wifi switch is turned on. If I execute the workaround, colors are reversed as described at the top of this report.

I built the next test kernel, up to the following commit:
a825bc87b2694dbefe39590a3efe29c5da4d3dd3

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the sixth test kernel and the results are no different from the third and fifth test kernels.

I built the next test kernel, up to the following commit:
cfb743bf6173063b57ef5a8185ea87f130209d4d

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the seventh test kernel and the results are no different from the third, fifth and sixth test kernels.

I built the next test kernel, up to the following commit:
ab0431059ed0d0e3a9e532ad0488ada25021249d

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the eighth test kernel and results are like for the fourth test kernel: rfkill list output shows only phy0 interface and dmesg | tail output shows a (back)trace. If I press the wifi switch button, network manager applet doesn't show any changes (no changes for rfkill list output too), but there is a low wifi led activity yet. If I execute the workaround, network manager applet doesn't show any changes again (no changes also for rfkill list output), but wifi led activity is interrupted (as expected).

I built the next test kernel, up to the following commit:
997daa1bd9aca412ab97955a35b26c460c0ec7a4

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

I tried the ninth test kernel and the results are no different from the fourth and eighth test kernels.

The bisect indicated the following commit as the first bad commit:

commit 997daa1bd9aca412ab97955a35b26c460c0ec7a4
Author: Alex Hung <email address hidden>
Date: Tue Oct 29 14:57:58 2013 +0800

    hp-wmi: detect "2009 BIOS or later" flag by WMI 0x0d for wireless cmd

I'll build a vivid test kernel with a revert of this commit and post a link to it shortly.

In order to revert commit 997daa1, I also had to revert: f82bdd0d. I built a Wily test kernel with both these commits reverted. The test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not?

Thanks for your work. Can build a test kernel for 32-bit systems? In the linked page I only see 64-bit .deb packages, while the architecture is 32 bits.

Sorry for that. There is now a 32 bit test kernel located at:

http://kernel.ubuntu.com/~jsalisbury/lp972604

Can you test that kernel and report back if it has the bug or not?

I've tried your last test kernel (4.0.0-1) and regression is disappeared: there are both hp-wifi and phy0 interfaces in rfkill list output, there are no (back)traces in dmesg | tail output and if I press the wifi switch button, network manager applet shows wifi status properly. Anyway, original bug (as described at the top of this report) exists yet: if I execute the workaround, colors are reversed.

Just to confirm, with the test kernel in #53, the wifi led blinks from red to blue continuously without your workaround?

Does the wifi still work even though the led is blinking from red to blue?

Yes, the wifi led blinks between red and blue, indicating network activity, in place of indicating wifi status. For example, it blinks heavily when loading a web page (it appears purple because of the speed). My workaround relatively because colors are reversed (as described at the top of this report).

Yes, wifi works when led blinks also. Your last test kernel removes the regression (but the original bug exists yet).

@Cristian,

Sorry I missed your message on IRC. I will be pinging upstream this week on the regression.

This bug may be fixed by upstream commit 8a1513b, which is in mainline as of the v4.3-rc2 kernel. That commit was also cc'd to stable. It is now in the Wily kernel, but not in Vivid or Trusty yet.

Can you test the latest Wily kernel and see if it fixes things? The Wily kernel can be downloaded from:
https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/8272202

I've tried 4.2.0-18.22 kernel by installing linux-image-4.2.0-18-generic_4.2.0-18.22_i386.deb and linux-image-extra-4.2.0-18-generic_4.2.0-18.22_i386.deb (available at https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/8272202 ). Using this kernel, regression is disappeared (same as 4.0.0-1 test kernel): there are both hp-wifi and phy0 interfaces in rfkill list output, there are no (back)traces in dmesg | tail output and if I press the wifi switch button, network manager applet shows wifi status properly. Anyway, original bug (as described at the top of this report) exists yet: if I execute the workaround, colors are reversed.

I'll install Ubuntu 15.10 too in order to confirm (or not) if the regression is definitively fixed and I'll update the bug report.

I've installed Wily Werewolf 15,10 (kernel 4.2.0-18-generic) and I can confirm regression is not present anymore. I can also confirm original bug exists yet (workaround generates same effects described above).

I've found a fix for the original bug (thanks to Bob Copeland): in kernel sources, go to drivers/net/wireless/ath/ath5k/led.c and change line 80 from:

 { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },

to:

 { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },

Save and recompile the ath5k module. After reloaded the module, simply execute the workaround (it just changes the triggers) described at the top of the bug report, so:

echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"
echo phy0radio > "/sys/class/leds/ath5k-phy0::rx/trigger"

will make wifi status to be shown properly by the led (the second parameter in ATH_LED macro represents the polarity of the pin).

I built a Wily test kernel with the fix mentioned in comment #60. Can you test this kernel and see if it resolves this bug? It can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp972604/

I've tried your last test kernel (4.2.0-27) and I confirm wifi status is shown properly by the led (after executing the workaround as described above and at the top of this bug report).

Hi Cristian,

Were you planning on submitting a patch upstream with your fix mentioned in comment #60?

I upload the patch file here (with the help of a developer). After tried your test kernel, I have not talked to any upstream guys and I have not written anywhere.

Fixed in Xenial via stable (commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream).

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug was fixed in the package linux - 4.4.0-25.44

---------------
linux (4.4.0-25.44) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1591289

  * Xenial update to v4.4.13 stable release (LP: #1590455)
    - MIPS64: R6: R2 emulation bugfix
    - MIPS: math-emu: Fix jalr emulation when rd == $0
    - MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC
    - MIPS: Don't unwind to user mode with EVA
    - MIPS: Avoid using unwind_stack() with usermode
    - MIPS: Fix siginfo.h to use strict posix types
    - MIPS: Fix uapi include in exported asm/siginfo.h
    - MIPS: Fix watchpoint restoration
    - MIPS: Flush highmem pages in __flush_dcache_page
    - MIPS: Handle highmem pages in __update_cache
    - MIPS: Sync icache & dcache in set_pte_at
    - MIPS: ath79: make bootconsole wait for both THRE and TEMT
    - MIPS: Reserve nosave data for hibernation
    - MIPS: Loongson-3: Reserve 32MB for RS780E integrated GPU
    - MIPS: Use copy_s.fmt rather than copy_u.fmt
    - MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU
    - MIPS: Prevent "restoration" of MSA context in non-MSA kernels
    - MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...)
    - MIPS: ptrace: Fix FP context restoration FCSR regression
    - MIPS: ptrace: Prevent writes to read-only FCSR bits
    - MIPS: Fix sigreturn via VDSO on microMIPS kernel
    - MIPS: Build microMIPS VDSO for microMIPS kernels
    - MIPS: lib: Mark intrinsics notrace
    - MIPS: VDSO: Build with `-fno-strict-aliasing'
    - affs: fix remount failure when there are no options changed
    - ASoC: ak4642: Enable cache usage to fix crashes on resume
    - Input: uinput - handle compat ioctl for UI_SET_PHYS
    - ARM: mvebu: fix GPIO config on the Linksys boards
    - ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description
    - ARM: dts: exynos: Add interrupt line to MAX8997 PMIC on exynos4210-trats
    - ARM: dts: imx35: restore existing used clock enumeration
    - ath9k: Add a module parameter to invert LED polarity.
    - ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
    - ath10k: fix debugfs pktlog_filter write
    - ath10k: fix firmware assert in monitor mode
    - ath10k: fix rx_channel during hw reconfigure
    - ath10k: fix kernel panic, move arvifs list head init before htt init
    - ath5k: Change led pin configuration for compaq c700 laptop
    - hwrng: exynos - Fix unbalanced PM runtime put on timeout error path
    - rtlwifi: rtl8723be: Add antenna select module parameter
    - rtlwifi: btcoexist: Implement antenna selection
    - rtlwifi: Fix logic error in enter/exit power-save mode
    - rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in
      rtl_pci_reset_trx_ring
    - aacraid: Relinquish CPU during timeout wait
    - aacraid: Fix for aac_command_thread hang
    - aacraid: Fix for KDUMP driver hang
    - hwmon: (ads7828) Enable internal reference
    - mfd: intel-lpss: Save register context on suspend
    - mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table
      correctly
    - PM / Runtime: Fix error path in pm_runtime_force_resume()
    - cpuidle: Indicate when a device has been unregiste...

I've tested the kernel in xenial-proposed installing the linux-image-4.4.0-25-generic and linux-image-extra-4.4.0-25-generic (#44 versions) by aptitude and the issue appears to be solved.

This bug was fixed in the package linux - 4.4.0-28.47

---------------
linux (4.4.0-28.47) xenial; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1595874

  * Linux netfilter local privilege escalation issues (LP: #1595350)
    - netfilter: x_tables: don't move to non-existent next rule
    - netfilter: x_tables: validate targets of jumps
    - netfilter: x_tables: add and use xt_check_entry_offsets
    - netfilter: x_tables: kill check_entry helper
    - netfilter: x_tables: assert minimum target size
    - netfilter: x_tables: add compat version of xt_check_entry_offsets
    - netfilter: x_tables: check standard target size too
    - netfilter: x_tables: check for bogus target offset
    - netfilter: x_tables: validate all offsets and sizes in a rule
    - netfilter: x_tables: don't reject valid target size on some architectures
    - netfilter: arp_tables: simplify translate_compat_table args
    - netfilter: ip_tables: simplify translate_compat_table args
    - netfilter: ip6_tables: simplify translate_compat_table args
    - netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
    - netfilter: x_tables: do compat validation via translate_table
    - netfilter: x_tables: introduce and use xt_copy_counters_from_user

  * Linux netfilter IPT_SO_SET_REPLACE memory corruption (LP: #1555338)
    - netfilter: x_tables: validate e->target_offset early
    - netfilter: x_tables: make sure e->next_offset covers remaining blob size
    - netfilter: x_tables: fix unconditional helper

linux (4.4.0-27.46) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1594906

  * Support Edge Gateway's Bluetooth LED (LP: #1512999)
    - Revert "UBUNTU: SAUCE: Bluetooth: Support for LED on Marvell modules"

linux (4.4.0-26.45) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1594442

  * linux: Implement secure boot state variables (LP: #1593075)
    - SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl

  * failures building userspace packages that include ethtool.h (LP: #1592930)
    - ethtool.h: define INT_MAX for userland

linux (4.4.0-25.44) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1591289

  * Xenial update to v4.4.13 stable release (LP: #1590455)
    - MIPS64: R6: R2 emulation bugfix
    - MIPS: math-emu: Fix jalr emulation when rd == $0
    - MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC
    - MIPS: Don't unwind to user mode with EVA
    - MIPS: Avoid using unwind_stack() with usermode
    - MIPS: Fix siginfo.h to use strict posix types
    - MIPS: Fix uapi include in exported asm/siginfo.h
    - MIPS: Fix watchpoint restoration
    - MIPS: Flush highmem pages in __flush_dcache_page
    - MIPS: Handle highmem pages in __update_cache
    - MIPS: Sync icache & dcache in set_pte_at
    - MIPS: ath79: make bootconsole wait for both THRE and TEMT
    - MIPS: Reserve nosave data for hibernation
    - MIPS: Loongson-3: Reserve 32MB for RS780E integrated GPU
    - MIPS: Use copy_s.fmt rather than copy_u.fmt
    - MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU
    - MIPS: Prevent "restoration" of MSA c...

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-wily' to 'verification-done-wily'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

I've tested the kernel in wily-proposed installing the linux-image-4.2.0-42-generic and linux-image-extra-4.2.0-42-generic (#49 versions) by aptitude and the issue appears to be solved.