View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015707||CentOS-7||kernel||public||2019-01-15 00:43||2019-09-20 21:53|
|Target Version||Fixed in Version||7.7-1908|
|Summary||0015707: Volume (and wireless) keys not working after upgrade|
|Description||When switching from 3.10.0-862.14.4 to|
the newest kernel (3.10.0-956.1.3),
the volume keys become unresponsive.
(asus-nb-wmi is the module responsible for this, afaik).
Also using the presenter key now results in an
unrecoverable black screen (not sure if related to the other keys, but also triggered by new kernel).
|Steps To Reproduce||Upgrade to kernel 3.10.0-956.1.3|
Try using volume up, down, mute, touchpad, wireless on a K73SV
|Additional Information||My laptop is a K73SV from ASUS.|
(Brightness up, down, disable screen are not affected)
Booting with the old kernel makes the keys work again.
workingkernel.log (64,860 bytes)
newkernel.log (65,127 bytes)
What is your wireless device?
lspci -nn | grep -i net
I meant to refer to the key toggling the wireless functionality, sorry for being unclear.
Either way it's:
Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe [1969:1083] (rev c0)
Sorry, mixed up the lines, this is the actual card:
03:00.0 Network controller : Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe [1814:5390]
Ok, I've downloaded the kernel sources I know the module is working on, and have recompiled
the module of 862 against the new headers of 956.
It makes no difference.
I could limit it to the function
"asus_wmi_evaluate_method" returning -5 (-EIO) as wmi_evaluate_method apparently returns without success
This function (wmi_evaluate_method) returns successfully with the old kernels while it fails with the newer one.
I have built the wmi module from 862 for 956.
This version works and the asus_wmi module from 956 also loads correctly this way.
Glad that you've got the way to fix the problem.
If I understand your procedure, you built the modules using the source code from the 862 kernel under CentOS 7.6 (-957):
Of which wmi.ko made the difference. Is this correct ?
Yes, that's correct.
I've built the modules from the 862 kernel under 957:
Then found, that by replacing the 957 version of wmi.ko with the 862 version built for 957,
fixes the issue.
If it helps I found that wmi_evaluate_method returns 0x1001
(Programmer exception and Bad parameter, if I'm not mistaken) with the 957 version, while it successfully returns with 862.
I only replaced the
wmi.ko in the end without rebuilding the other modules, though.
To be clear:
Current setup (working):
asus-laptop.ko(957) (not loaded, so probably irrelevant)
I hope I don't spam your inbox.
If I did I'm sorry.
This kind of 'spam' is welcome.
Now only if we can find a fix for the issue. This is something that needs reporting upstream at http://bugzilla.redhat.com .
[EDIT] What I meant by a "fix" is a "kernel patch" to fix the issue.
Could you run some tests? I want you to try and see if the newer kernels from kernel.org have this problem fixed. You can use kernel-lt (4.4.x) or kernel-ml (4.20.x) from ELRepo:
@Fighter19, with your great analysis, I suspect this should fix your problem https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fe57261214bcc866ef0233444a395b5fdfb5ac3
If we build un unsigned version of the kernel-plus, would you be able to test it?
A set of centosplus kernel with @pgreco's patch is now available from:
If you wish to do a 'quick and dirty' check with the modules, they can be found here:
I've tried the 'quick and dirty' check with the modules.
It seems that this patch fixes the problems.
I've installed the patched centosplus kernel.
The keys also work with this one.
Although following packages could not be installed due to conflicts with their "normal" kernel counterparts:
kernel-plus-headers.x86_64 0:3.10.0-957.1.3.el7.centos.plus.bug15707 kernel-plus-tools.x86_64 0:3.10.0-957.1.3.el7.centos.plus.bug15707
kernel-plus-tools-libs.x86_64 0:3.10.0-957.1.3.el7.centos.plus.bug15707 kernel-plus-tools-libs-devel.x86_64 0:3.10.0-957.1.3.el7.centos.plus.bug15707
But I guess this is not an issue.
That's great news. @pgreco will be filing a bug report upstream. :)
Sorry, I did not make it clear. You do not need to install the -header package. It is designed to conflict with the distro kernel.
|Also, future updates to the plus kernel will have the patch. So if you keep using it, you don't have to build the modules yourself. Hopefully the patch gets added to the upstream (RHEL) kernel, so the CentOS distro kernel gets it, too.|
@toracat bug filed upstream https://bugzilla.redhat.com/show_bug.cgi?id=1667232
@Fighter19 do you have bugzilla.redhat.com account so you can follow the progress there?
|I just created one, however I'm unable to see the page there.|
@Fighter19 Yeap, that is why I asked. Kernel bugs are automatically marked as "private", so only people in the cc list can read (apart from RH developers).
If you send me the mail you used to register, I can add you to the cc.
|kernel-plus-3.10.0-957.5.1.el7.centos.plus now has the patch.|
@Fighter19, don't know if you get mail from the upstream bug, but there is a kernel for you to test.
|Closing, this was solved in 7.7.1908|
|2019-01-15 00:43||Fighter19||New Issue|
|2019-01-15 00:43||Fighter19||File Added: workingkernel.log|
|2019-01-15 00:43||Fighter19||File Added: newkernel.log|
|2019-01-15 00:43||Fighter19||Tag Attached: 3.10.0-956.1.3|
|2019-01-15 01:23||toracat||Note Added: 0033585|
|2019-01-15 01:48||Fighter19||Note Added: 0033586|
|2019-01-15 01:50||Fighter19||Note Added: 0033587|
|2019-01-15 03:01||Fighter19||Note Added: 0033588|
|2019-01-15 03:21||Fighter19||Note Added: 0033589|
|2019-01-15 19:57||toracat||Note Added: 0033595|
|2019-01-15 19:58||toracat||Status||new => acknowledged|
|2019-01-15 19:58||toracat||Description Updated||View Revisions|
|2019-01-15 19:58||toracat||Steps to Reproduce Updated||View Revisions|
|2019-01-15 19:58||toracat||Additional Information Updated||View Revisions|
|2019-01-15 23:24||Fighter19||Note Added: 0033596|
|2019-01-15 23:25||Fighter19||Note Added: 0033597|
|2019-01-15 23:27||Fighter19||Note Added: 0033598|
|2019-01-15 23:28||Fighter19||Note Added: 0033599|
|2019-01-16 08:44||toracat||Note Added: 0033603|
|2019-01-16 20:10||toracat||Note Edited: 0033603||View Revisions|
|2019-01-16 20:19||toracat||Note Edited: 0033603||View Revisions|
|2019-01-16 20:28||toracat||Note Added: 0033608|
|2019-01-16 22:24||pgreco||Note Added: 0033610|
|2019-01-17 00:35||toracat||Note Added: 0033611|
|2019-01-17 00:35||toracat||Status||acknowledged => feedback|
|2019-01-17 18:04||Fighter19||Note Added: 0033617|
|2019-01-17 18:04||Fighter19||Status||feedback => assigned|
|2019-01-17 18:23||Fighter19||Note Added: 0033618|
|2019-01-17 18:27||toracat||Note Added: 0033619|
|2019-01-17 18:29||toracat||Note Added: 0033620|
|2019-01-17 18:32||toracat||Note Added: 0033621|
|2019-01-17 19:29||pgreco||Note Added: 0033624|
|2019-01-17 23:32||Fighter19||Note Added: 0033628|
|2019-01-18 00:01||pgreco||Note Added: 0033629|
|2019-01-31 18:31||toracat||Note Added: 0033742|
|2019-03-05 18:44||pgreco||Note Added: 0033941|
|2019-09-20 21:53||pgreco||Status||assigned => closed|
|2019-09-20 21:53||pgreco||Resolution||open => fixed|
|2019-09-20 21:53||pgreco||Fixed in Version||=> 7.7-1908|
|2019-09-20 21:53||pgreco||Note Added: 0035173|