Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working with Kernel 5.11 #32

Closed
JoniHartikainen opened this issue Nov 25, 2021 · 26 comments
Closed

Not working with Kernel 5.11 #32

JoniHartikainen opened this issue Nov 25, 2021 · 26 comments

Comments

@JoniHartikainen
Copy link

I don't know if it's just me but the package stopped working with kernel 5.11.

@jibsaramnim
Copy link

I'm not the creator, but I thought I'd try to a few more questions to see if we could possibly figure this out: Could you share what steps you tried to take, and if you updated to 5.11 or if this is a freshly installed OS?

In my case I've been keeping the module working after each kernel update by removing it first (sudo dkms remove -m asus-wmi -v 1.0 --all), then rebooting so the system is running the new kernel version, then patching the module to work with the newly installed/running kernel (sudo sh prepare-for-current-kernel.sh), then re-adding it (sudo dkms add -m asus-wmi -v 1.0), building it (sudo dkms build -m asus-wmi -v 1.0), and installing it (sudo dkms install -m asus-wmi -v 1.0). Then, after one more reboot, it should show up again. It's a bit cumbersome to say the least, but it's working, at least for the kernel versions I've been running (the latest being 5.14.18 as of this writing).

These steps may be obvious, but I thought I'd share them anyway just in case. Initially I was a bit confused when after the very first minor (x.x.1) kernel update the module stopped working, even though the README says dkms should be keeping things up-to-date automatically for minor kernel updates. In my experience I've had to do these steps manually for every single kernel update, minor or otherwise.

@JoniHartikainen
Copy link
Author

I did it as instructed, but it just didn’t work. /sys/class/leds/asus::screenpad is missing after startup.

@s-light
Copy link
Contributor

s-light commented Dec 3, 2021

that seems to be the same for me.

and i have some more info:
i just updated my system from kubuntu 20.04 to kubuntu 21.10
(before the update it worked nicely.)
with this i got the new higher kernel version also:

$ uname -r
5.11.0-41-generic

after this did the normal refresh things... (installation steps)
and the module in itself is somehow working-
my keyboard actions for the special keys over the touchpad are working!
but i also do not get any /sys/class/leds/asus::screenpad/brightness

seems in the led driver area is something different....

@macbrownzie
Copy link

I'm not the creator, but I thought I'd try to a few more questions to see if we could possibly figure this out: Could you share what steps you tried to take, and if you updated to 5.11 or if this is a freshly installed OS?

In my case I've been keeping the module working after each kernel update by removing it first (sudo dkms remove -m asus-wmi -v 1.0 --all), then rebooting so the system is running the new kernel version, then patching the module to work with the newly installed/running kernel (sudo sh prepare-for-current-kernel.sh), then re-adding it (sudo dkms add -m asus-wmi -v 1.0), building it (sudo dkms build -m asus-wmi -v 1.0), and installing it (sudo dkms install -m asus-wmi -v 1.0). Then, after one more reboot, it should show up again. It's a bit cumbersome to say the least, but it's working, at least for the kernel versions I've been running (the latest being 5.14.18 as of this writing).

These steps may be obvious, but I thought I'd share them anyway just in case. Initially I was a bit confused when after the very first minor (x.x.1) kernel update the module stopped working, even though the README says dkms should be keeping things up-to-date automatically for minor kernel updates. In my experience I've had to do these steps manually for every single kernel update, minor or otherwise.

Hello jibsaramnim,

Did you have to update the prepare-for-current-kernel.sh and / or patch or patch5.8 to make it work with the newer kernels? My thinking from looking at the script is that the patch set was one way (patch) for kernel 5.7 and then we needed a different patch (patch5.8) that was used for 5.8 and 5.9. Since the prepare isn't matching against 5.10 or beyond, maybe the problem is as simple as making the default patch5.8 instead of patch.

Are you doing something similar to get it working of 5.10 +?

Thanks,
_Macbrownzie

@jibsaramnim
Copy link

Hi Macbrownzie,

I did not make any changes no, I simply re-ran the prepare-for-current-kernel.sh script as-is, and it works just fine, at least on my setup. I can see it downloading the correct looking files matching the kernel version I'm currently running, and /sys/class/leds/asus::screenpad/brightness shows up and works as expected too.

I'm not entirely sure how this could be related, but the only difference I'm seeing right now between the reports (Including #33) is that it seems everyone having this issue is running Ubuntu (or a derivative of), whereas I'm running Fedora. But how that could affect something Kernel-level, I'm not sure.

Have you looked through your system journal logs after a boot? I wonder if there might be something reported there.

@macbrownzie
Copy link

Hi Macbrownzie,

I did not make any changes no, I simply re-ran the prepare-for-current-kernel.sh script as-is, and it works just fine, at least on my setup. I can see it downloading the correct looking files matching the kernel version I'm currently running, and /sys/class/leds/asus::screenpad/brightness shows up and works as expected too.

I'm not entirely sure how this could be related, but the only difference I'm seeing right now between the reports (Including #33) is that it seems everyone having this issue is running Ubuntu (or a derivative of), whereas I'm running Fedora. But how that could affect something Kernel-level, I'm not sure.

Have you looked through your system journal logs after a boot? I wonder if there might be something reported there.

Good Evening Jibsaramnim,

I did a quick grep for WMI through the journalctl after my last boot and this is what I see.
Dec 05 19:40:50 Zenbook kernel: acpi PNP0C14:04: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:03)
Dec 05 19:40:50 Zenbook kernel: acpi PNP0C14:05: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:03)
Dec 05 19:40:50 Zenbook kernel: asus_wmi: ASUS WMI generic driver loaded
Dec 05 19:40:51 Zenbook kernel: asus_wmi: BIOS WMI version: 9.0
Dec 05 19:40:51 Zenbook kernel: asus-nb-wmi asus-nb-wmi: Detected ATK, not ASUSWMI, use DSTS
Dec 05 19:40:51 Zenbook kernel: input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input26

Can you check to see if you see similar entries on your box?

Thanks,
_Macbrownzie

@jibsaramnim
Copy link

I'm seeing similar results on mine after a fresh boot:

Dec 06 11:57:19 dos kernel: acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
Dec 06 11:57:19 dos kernel: acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
Dec 06 11:57:35 dos kernel: asus_wmi: ASUS WMI generic driver loaded
Dec 06 11:57:35 dos kernel: asus_wmi: BIOS WMI version: 9.0
Dec 06 11:57:35 dos kernel: asus-nb-wmi asus-nb-wmi: Detected ATK, not ASUSWMI, use DSTS
Dec 06 11:57:35 dos kernel: input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input38

This is while running on Kernel 5.15.5. I guess at boot at least the logs aren't very useful. I wonder if anything might've shown up when building the module?

@macbrownzie
Copy link

macbrownzie commented Dec 6, 2021

Here is the output of the prepare-for-current-kernel.sh

--2021-12-05 20:14:44--  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/drivers/platform/x86/asus-wmi.c?h=linux-5.13.y
Resolving git.kernel.org (git.kernel.org)... 139.178.84.217, 2604:1380:4641:c500::1
Connecting to git.kernel.org (git.kernel.org)|139.178.84.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 72575 (71K) [text/plain]
Saving to: ‘asus-wmi.c’

asus-wmi.c                                    100%[===============================================================================================>]  70.87K  --.-KB/s    in 0.05s

2021-12-05 20:14:44 (1.29 MB/s) - ‘asus-wmi.c’ saved [72575/72575]

--2021-12-05 20:14:44--  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/drivers/platform/x86/asus-wmi.h?h=linux-5.13.y
Resolving git.kernel.org (git.kernel.org)... 139.178.84.217, 2604:1380:4641:c500::1
Connecting to git.kernel.org (git.kernel.org)|139.178.84.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2215 (2.2K) [text/plain]
Saving to: ‘asus-wmi.h’

asus-wmi.h                                    100%[===============================================================================================>]   2.16K  --.-KB/s    in 0s

2021-12-05 20:14:45 (1.86 GB/s) - ‘asus-wmi.h’ saved [2215/2215]

--2021-12-05 20:14:45--  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/drivers/platform/x86/asus-nb-wmi.c?h=linux-5.13.y
Resolving git.kernel.org (git.kernel.org)... 139.178.84.217, 2604:1380:4641:c500::1
Connecting to git.kernel.org (git.kernel.org)|139.178.84.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16940 (17K) [text/plain]
Saving to: ‘asus-nb-wmi.c’

asus-nb-wmi.c                                 100%[===============================================================================================>]  16.54K  --.-KB/s    in 0.03s

2021-12-05 20:14:45 (643 KB/s) - ‘asus-nb-wmi.c’ saved [16940/16940]

patching file asus-nb-wmi.c
Hunk #1 succeeded at 544 (offset -34 lines).
Hunk #2 succeeded at 554 (offset -34 lines).
Hunk #3 succeeded at 568 (offset -34 lines).
patching file asus-wmi.c
Hunk #2 succeeded at 191 (offset 4 lines).
Hunk #3 succeeded at 722 (offset 30 lines).
Hunk #4 succeeded at 867 (offset 30 `lines).`

I didn't see anything reported in journalctl when I built it.   

The add was also successful: 
`Creating symlink /var/lib/dkms/asus-wmi/1.0/source ->
                 /usr/src/asus-wmi-1.0

DKMS: add completed.```

The build appears to have been unnecessary: 
```Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j12 KERNELRELEASE=5.13.0-22-generic -C /lib/modules/5.13.0-22-generic/build M=/var/lib/dkms/asus-wmi/1.0/build...
Signing module:
 - /var/lib/dkms/asus-wmi/1.0/5.13.0-22-generic/x86_64/module/asus-wmi.ko
 - /var/lib/dkms/asus-wmi/1.0/5.13.0-22-generic/x86_64/module/asus-nb-wmi.ko
Nothing to do.
cleaning build area...

DKMS: build completed.```

And the modules appear to be loaded now.
```asus_nb_wmi            28672  0
asus_wmi               40960  1 asus_nb_wmi
sparse_keymap          16384  1 asus_wmi
wmi                    32768  4 intel_wmi_thunderbolt,asus_wmi,wmi_bmof,mxm_wmi
video                  53248  2 asus_wmi,i915```

And the install: 
```asus-wmi.ko:
Running module version sanity check.
 - Original module
 - Installation
   - Installing to /lib/modules/5.13.0-22-generic/updates/dkms/

asus-nb-wmi.ko:
Running module version sanity check.
 - Original module
 - Installation
   - Installing to /lib/modules/5.13.0-22-generic/updates/dkms/

depmod...

DKMS: install completed.```

That time when I ran it, it appears to have created the asus::screenpad directory.   I am going to reboot and see if it comes back. 

@jibsaramnim
Copy link

Note that you can wrap code snippets or logs in three back ticks (```, both at the beginning and the end of the snippet) to have them show up in a more legible way, right now it's a wee bit difficult to see where the logs end and your personal remarks start :).

From what I can tell that looks about the same as what happens on my system, though I'm not sure if it mentioned anything about the build step not being necessary. I just ran everything again as there was a kernel update waiting for me (now 5.15.6), and after upgrading to it, removing the module, rebooting, and doing all the build steps as mentioned before then rebooting again, it's still working as expected. I hope you have the same result now that you tried again! :)

@macbrownzie
Copy link

I feel like we are getting closer. The modules all loaded so upon boot I have asus_wmi and asus_nb_wmi, but no /sys/class/leds/asus::screenpad/brightness.

I rmmod(ed) the asus_wmi module (which required removing the asus_nb_wmi and something called aaeon and then modprobed them all back in and the asus::screenpad file appeared and after the chmod it is working again.

So... maybe it is a module load order? Do you have the aaeon module on your system?

Thanks again for your help!

PS: I will go update the last post, thanks for the suggestion.

@jibsaramnim
Copy link

jibsaramnim commented Dec 6, 2021

Do you have the aaeon module on your system?

I don't think I do, lsmod | grep aaeon shows up nothing. I have no idea what that module is for either, did that come with your system, or is it related to some kind of hardware you're using?

So... maybe it is a module load order?

There's a Troubleshooting section in the README referencing a possible load order issue, could this be what the readme is referring to? It seems to suggest replacing the installed modules with symlinks to a different version of the same modules? I'm not entirely sure what that would do, but if that gets you to a working system it'll sure be great :).

Edit: I forgot to mention, if this AAEON module (is it related to this perhaps? No idea why that would come pre-installed with Ubuntu on a laptop, huh) isn't used, maybe blacklisting it would already be enough to solve the module load order issue that might be happening here?

@macbrownzie
Copy link

macbrownzie commented Dec 6, 2021

SUCCESS!

I did a couple of searches for the mfd_aaeon module and couldn't find what it is used for, so I decided to disable it for the time being. With it blacklisted (and the initramfs updated) the asus_wmi and asus_nb_wmi load and the screenpad works as expected.

So to answer your earlier question, I think the difference between the distributions is what kernel modules are loaded by default.

If anyone has information on the mfd_aaeon, I would really appreciate you posting it here.

Thanks for your help.

@jibsaramnim
Copy link

jibsaramnim commented Dec 6, 2021

If anyone has information on the mfd_aaeon, I would really appreciate you posting it here.

AAEON seems to be a subsidiary of ASUS, focusing on embedded boards and related. Related to the link I posted previously, and here's their official website. I found a relevant patch note in the Ubuntu kernel mailing list here, though I have no idea why or how this ended up in the main Ubuntu release, seemingly loading this module for any Asus computer that loads asus-wmi. That seems to be a bit of an oversight, unless I'm missing something.

SUCCESS!

This is great news though!

@HartnetDev @s-light could you try seeing if you too have the mfd_aaeon kernel module on your systems, and if blacklisting gets the screenpad brightness part of this module working for you too?

I am not on Ubuntu, but I believe you should also be able to use lsmod to find installed modules (e.g. sudo lsmod | grep aaeon). To blacklist the module you can create a conf file for it, something like this should do the trick:

echo "blacklist mdf_aaeon" > sudo tee /etc/modprobe.d/aaeon-blacklist.conf

I believe Ubuntu comes with update-initramfs, so updating for all installed kernels should be sudo update-initramfs -k all -u.

Sorry if you knew all this already, but I figured I'd share just in case it's helpful. I for one can never remember these commands myself 😅.

I hope this gets things working for you both too. And if it does, it'd be great if you could report back here for anyone else who might run into this in the future. Thank you! :)

@macbrownzie
Copy link

Yep, it seems odd that this module would be included in the standard Ubuntu build.. or even with the rest of the asus-wmi modules. Thanks again for your help on figuring this out.

@JoniHartikainen
Copy link
Author

JoniHartikainen commented Dec 6, 2021

If anyone has information on the mfd_aaeon, I would really appreciate you posting it here.

AAEON seems to be a subsidiary of ASUS, focusing on embedded boards and related. Related to the link I posted previously, and here's their official website. I found a relevant patch note in the Ubuntu kernel mailing list here, though I have no idea why or how this ended up in the main Ubuntu release, seemingly loading this module for any Asus computer that loads asus-wmi. That seems to be a bit of an oversight, unless I'm missing something.

SUCCESS!

This is great news though!

@HartnetDev @s-light could you try seeing if you too have the mfd_aaeon kernel module on your systems, and if blacklisting gets the screenpad brightness part of this module working for you too?

I am not on Ubuntu, but I believe you should also be able to use lsmod to find installed modules (e.g. sudo lsmod | grep aaeon). To blacklist the module you can create a conf file for it, something like this should do the trick:

echo "blacklist mdf_aaeon" > sudo tee /etc/modprobe.d/aaeon-blacklist.conf

I believe Ubuntu comes with update-initramfs, so updating for all installed kernels should be sudo update-initramfs -k all -u.

Sorry if you knew all this already, but I figured I'd share just in case it's helpful. I for one can never remember these commands myself sweat_smile.

I hope this gets things working for you both too. And if it does, it'd be great if you could report back here for anyone else who might run into this in the future. Thank you! :)

Hello Jibsaramnim,

I tried the following commands on Ubuntu:

sudo echo "blacklist mfd_aaeon" > /etc/modprobe.d/aaeon-blacklist.conf
sudo update-initramfs -k all -u
sudo reboot

Result: Didn't work

So I tried reinstalling once more:

sudo dkms remove -m asus-wmi -v 1.0 --all && sudo rm -r /usr/src/asus-wmi-1.0 && sudo mkdir /usr/src/asus-wmi-1.0 && cd /usr/src/asus-wmi-1.0 && sudo wget 'https://github.com/Plippo/asus-wmi-screenpad/archive/master.zip' && sudo unzip master.zip && sudo mv asus-wmi-screenpad-master/* . && sudo rmdir asus-wmi-screenpad-master && sudo rm master.zip && sudo sh prepare-for-current-kernel.sh && sudo dkms add -m asus-wmi -v 1.0 && sudo dkms build -m asus-wmi -v 1.0 && sudo dkms install -m asus-wmi -v 1.0
sudo reboot

Result: SUCCESS!

Adding the Aaeon module to the blacklist helped me get out of my misery.
Thank you!

@s-light
Copy link
Contributor

s-light commented Dec 6, 2021

@jibsaramnim i appreciate your clear steps to test!
(yeah i could research what tools / commands i need - and iam sure i have used them in the past..... ;-) )

$ sudo lsmod | grep aaeon
[sudo] password for stefan: 
mfd_aaeon              16384  0
asus_wmi               40960  2 asus_nb_wmi,mfd_aaeon
wmi                    32768  5 intel_wmi_thunderbolt,asus_wmi,wmi_bmof,mfd_aaeon,mxm_wmi

so it seems yeah i have this thing on my system...

yeah!
after the blacklisting and and update-initramfs
it is working again for me :-)

in detail:

  • blacklisting
  • rebuilding
  • reboot
  • not working
  • remember that i have forget to update-initramfs
  • reboot
  • working

👍
thanks @jibsaramnim for your help on spotting this!!

@jibsaramnim
Copy link

Awesome! I’m glad it’s working again for both of you! And it was @macbrownzie who found this rogue module throwing a wrench into things, not me. But I’m very glad we were able to figure this out. It’s such a nice laptop, it would be a waste if you both had to use Windows on it ;-)

@s-light
Copy link
Contributor

s-light commented Dec 6, 2021

sorry yeah thanks @macbrownzie for finding!!

no way i will use windows.... ;-)

the next days i get my replacement battery (as my currently only has left 31% capacity...)
and in the replacement process i will take some good pictures from the inside -
if anybody has special ideas what he wants details on please let me know -
i will only dissassamble as fare as i need for battery replacement..
(its my main work tool - so no long off-times possible...)

@macbrownzie
Copy link

Good Morning All,
It sounds like we found the cause or at least a workaround and can probably close this issue.

Since upgrading to Ubuntu 21.10 I have noticed that resuming the laptop after it goes to sleep or just after the screen saver isn't working right. The main OLED display doesn't come back on. The screenpad does and my external monitor (connected over USBC through a port replicator) does, but of course the login box is on the main OLED panel... so that makes it a bit tricky.

Sometimes just closing and opening the lid restores the OLED, but today I had to switch to a text console and then switch back to X/Wayland.

Any suggestions would be appreciated.

_Macbrownzie

@jibsaramnim
Copy link

Since upgrading to Ubuntu 21.10 I have noticed that resuming the laptop after it goes to sleep or just after the screen saver isn't working right. The main OLED display doesn't come back on.

That's odd.. I'm not sure if I'll be able to be of any use here unfortunately, My Zenbook Duo Peasant Edition™ does not seem to have this issue, but at the same time I never use it with an external monitor either. You have probably considered this already, but reviewing journalctl might help uncover what's going on?

If your unit has an NVidia GPU, it might be worth looking into possible driver woes there. It seems like the newest drivers are causing trouble for a lot of people. I'm not sure if this issue you're having could be related to NVidia's drivers, but if you do have a dedicated GPU in yours and you're running the 495.xx (I believe) driver version, you could try downgrading to 470.xx and see if that helps?

@zyydavid
Copy link

TTTTTTThank you guys!!!!! After blacklisting the aaeon module, it works!!!!! asus::screenpad directory occurs!!!! It has cost me the whole day to figure out!! Thanks again! You help me a lot! My ZenBook come to live!!

@s-light
Copy link
Contributor

s-light commented Jan 11, 2022

It sounds like we found the cause or at least a workaround and can probably close this issue.

if we mention this in the Troubleshooting section of the readme yes i think so too ;-)

@s-light
Copy link
Contributor

s-light commented Jan 11, 2022

done in #34

@Plippo
Copy link
Owner

Plippo commented Jan 11, 2022

A big thank you to all of you for investigating the issue and thanks @s-light for the additions to the readme file. I've merged the pull request. Closing the bug.

@Plippo Plippo closed this as completed Jan 11, 2022
@s-light
Copy link
Contributor

s-light commented Jan 11, 2022

thanks for merging :-)

@s-light
Copy link
Contributor

s-light commented Jan 24, 2022

just did this again.
and found that also i have blacklistet and it is working all if i do a

$ lsmod | grep aaeon
mfd_aaeon              16384  0
asus_wmi               40960  2 asus_nb_wmi,mfd_aaeon
wmi                    32768  5 intel_wmi_thunderbolt,asus_wmi,wmi_bmof,mfd_aaeon,mxm_wmi

i get info that the module is loaded...
i thought with the blacklist is should not load anymore...

and the puzzling thing is - first it did not work -
and than it worked...
so maybe there is more to it -
but hey - essential is it is working ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants