-
Notifications
You must be signed in to change notification settings - Fork 27
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
[UNSUPPORTED HARDWARE: ZenBook UX3410UA] module load fails #44
Comments
Ok. I cloned the repo to "/usr/src", called "make DEBUG=1" and ran "./misc/test_module.sh".
WITH "force_load=1" I got:
dmesg returned:
Btw. How would I execute those API calls? Is there some way to do it via bash or is only C the way to go? |
Can you please also show me the dmesg output (of the debug-build-module) after you tried to further acpi_call is under the line just a kernel module which allows you "echoing" into your acpi also from the bash for example. there will surely be a package, if you don't have it anyways, just go for a |
Oh. Sorry the dmesg output was using
|
I can toy around with the ACPI calls via |
uh, ok so there I see a dmesg message without for acpi, see this post there you see what to echo into the acpi call file ... looks like disabling the auto-mode is the evil part here:
So there is this acpi entry handling this, currently with 2 params, 0 0 |
I installed |
At least root should be able to execute it... |
you should try it directly being root, and with ""....
This should be the roughly the output, try out some combinations as to be seen in the other post, especially the SFNV above. The argument "0" leads to low fan speeds on my side, using "1" and or "2" leads to very low (if not off) running fans... Try it out please and tell me if you hear any difference.... |
I get:
(empty result, just an empty line) |
I've got a UX310UAK here, which is internally the same as @HorstBaerbel's UX410UAK. Also have to force load the module. Using asus-fan I can manually set the fan speed. lm sensors even reports the fan speed according to the set speed. The fan doesn't actually change it's speed though. lm-sensors does show the actual speed of the fan when set to auto. I've included the test_module.sh and acpi_call output below. Hope it helps, would be nice if we can get this to work. test_module.sh output:
I got the following from acpi_call:
|
Hi, build + install:
Running the tests with force_load=1 as otherwise loading fails when trying to set auto-mode :
corresponding dmesg:
The fan speed is not changing during the test. I also played a bit around with manually setting the fan speed via sysfs without success. The fan always seems to stay in auto mode, even though you can read out the previously set speed. My results from api_call:
|
Hi, I have Asus UX360UAK and experience the same issue: asus_fan module fails to load, if forced to load it shows current temp/fan status but does not change fan speed. When I try ACPI calls I see the same result as @pasdVn, i.e. "_SB.PCI0.LPCB.EC0.SFNV" and "_SB.ATKD.QMOD" are missing. After much tinkering with decompiled DSDT I found ACPI calls which can replace missing ones:
For GPU following calls should work but I cannot test them as my laptop does not have GPU:
I am going to do quick and dirty update of current asus_fan.c for use on my laptop, however I think proper solution would auto-detect laptop model and select appropriate ACPI calls (or try original method first and fall-back to that more hacky one for newer laptops) which is beyond my C abilities. Thank you for making this kernel module available! |
Nice! It looks like this is going somewhere... Will try the ACPI calls on my laptop too when I find time. |
I found thermal tipping point table in embedded controller RAM. It is between addresses 0x537. 0x53e. Default table: I have adjusted tipping points to following temp values and my laptop is silent most of the time: ACPI calls to achieve that:
Pros of this approach:
Cons:
It would be nice to expose these adjustments via asus_fan kernel module. |
Proof-of-concept script to tweak cooling profile: |
It might sound stupid, but I'm stuck using acpi_call. I do
Which should read from ADDRESS. It does not matter what address I use, I always get the result
I tried addresses around 0x100, 0x200 and 0x537-53b, but always get the same result. What am I doing wrong with acpi_call?! |
@HorstBaerbel, WRAM call requires two arguments: |
Doh, Thanks. "RRAM" for reading makes sense... |
It takes 10-20 seconds for changes in these values to become effective on my laptop and it also switches the fan on/off when there are load spikes. In the end I set the first threshold to 48C to make this annoyance less frequent. Also it seems fan reacts not only to CPU but also WiFi module temperature which is 5C hotter than CPU when idling in non-power-save mode. |
So what I did for now was adding
(mind the escaping) Then do a |
Sounds like this is a clear candidate to be exposed using asus_fan ... |
@afilipovich your replacement for the |
The module is now working on my UX3410UA. See my (preliminary) commit here. |
nice to see it working, great stuff... the models system sounds like a pretty good idea to have a clean separation for the models. |
Just a conceptional question: What is fan auto mode supposed to do? Reset the fan to its default behaviour / EC control? |
Yes, |
OK. This is somehing in between manual and auto mode... What should I call it, should I add another sysfs entry? |
I would say this is "auto", but adjustable. |
@afilipovich So far I didn't find any better way how to directly say thank you as you have made possible creating my asus-fan-control repository, mainly focused on my ASUS ZenBook UX430UA and later being extended to support ASUS ROG Strix GL553VD as well. The very core of the mentioned project stands on this comment in this issue. So thank you! 😃 @daringer I am sorry for the "spam" in this issue, but @afilipovich has no public email in his GitHub profile and I want to let him know. |
Thank you @dominiksalvet! I still remember the day when that annoying fan went quiet :) |
I can confirm it works on UX430UNR (54 58 62 66 72 78 88 96).
FWIW: Using systemd-tmpfiles works perfectly:
On my laptop the fan spins up at 54° and spins down at ~40°, but if i change the first tipping point to 58° the fan spins down at ~45°. Does the controller use some kind of sliding offset for spin down? maybe? A few test scripts, maybe they are useful for someone. Read all tipping points (0x537-0x53e)
Read all (?) EC memory
|
Not related to fan control at all, but I think some of you could find the information useful. Most newer Zenbooks supports battery charge control (https://www.asus.com/us/support/FAQ/1032726/). So I did some tinkering and found the relevant address (Zenbook UX430UNR, bios 308):
I use the following, to limit the battery to max 80%:
|
Support for newer Zenbooks should be supported out-of-the-box when this patch gets merged (5.4 or maybe 5.3). |
@daringer Oops, here we go again... but you already know the email address thing, don't you? Sorry for that... still could not help myself. 😢 @klausenbusk Hey man! Do you know about asus-fan-control? It does basically the same as your script for setting temperature does but in a more sophisticated and consistent way - it sets all temperatures, performs various checks, it supports a decent amount of ASUS laptop models and much more. Thanks to @agura-lex we also have systemd integration and an AUR package for our dear Arch users. Your model name seems to be very similar to mine (UX430UA), so there is a decent chance it will work out of the box (but explicitly adding it as tested would be really great). Please, consider giving asus-fan-control a try. 😄 @klausenbusk BTW thank you so much for the code snippets above. ❤️ Some people have reported me that asus-fan-control did not work on their devices and I have been thinking a bit what to do with that. Once I had seen your snippets, I got an idea and I have created afc-scout, which you can basically use to find your base ACPI fan address by reading a given ACPI address range. Yep, you need to process it manually but it is certainly better than nothing! 🚀 |
HAHA, this is pretty next level: direct-marketing at the competitor, at least you come over to visit asus-fan - but seriously: no worries, it's not like this is a competition for the highest number of hardware-specific adaptations within some piece of code 🤓 Personally I believe hardware should not be controlled by bash scripts (too often) :D so it will be tough for you to get me to asus-fan-control and if your project gets better because of the discussions/investigations here, it's already win-win. Despite the fact that afc-scout will be helpful to support more models, so keep up the good work. At least until I have a zenbook again 👍 😩 But this is already around the corner, will for sure use |
@daringer Glad to hear that! I have no interest to compete with asus-fan. We both develop software that does basically the same (except for two fans support) but we use different approaches. I understand your skepticism about "bash scripts" but keep in mind that my scripts are almost without an exception POSIX shell scripts and so they run practically everywhere without any special dependencies (even on macOS and even these days). I also realize the fact that shell scripts may be very fragile and hence I really keen on mechanisms preventing those issues - AND/OR lists, no command substitution in another command's parameter, no pipes (except with echo), no non-POSIX command options, functions, which modify calling shell's environment, are strictly put into their own subshells, etc. BTW, I really wouldn't post here if @klausenbusk had an email address on his GitHub profile. For the sake of completeness, @afilipovich really did not have an email address on his profile that time (in case you miss it)... He just reacted quickly and added it. 😄 Hope you will be happy with a new ZenBook! 🚀 |
Finding a email address for a Github user isn't hard if they have some public activity :)
It is hard to compete with
The Out of curiosity: Are you experiencing throttling on your model? My CPU was capped at ~8w (IIRC) until I did: https://github.com/erpalma/throttled/tree/88216b119ad512d6d345e66dd304ba7b6b3e93c0#static-fix |
@klausenbusk Thanks man! Didn't know about the email address. 👍 I would gladly add your model as tested but since you haven't tried it with asus-fan-control, I can't do so. 😢 But I completely understand your argument of simplicity and I respect it! 😄 Still, should you change your mind, make sure you will add your model, please. Here is the thing with writing to "random" EC addresses... The fact that there is no such flag from the very beginning of asus-fan-control is probably the main reason why asus-fan-control is not called ux430ua-fan-control as was initially... BTW, I think that afc-scout brings at least something to the table in this matter... 😄 I do not notice any symptoms of CPU throttling on my device. BTW, I have i5-7200U and default UX430UA asus-fan-control configuration... 🚀 Ok, I am truly sorry @daringer for the spam and since now I know how to reach people even without public GitHub email, this is most likely my last post here. Also, feel free to remove my posts here (e.g., in a week) as their messages have been delivered and I must admit that they do not contribute to this issue very much. Nevertheless, thank you so much for the given space! ❤️ |
@dominiksalvet, absolutly ok, it drives things/projects forward, you have my full support :D |
You should point out about asus-fan-control in the readme |
Hey, thanks and good tests, let's see if we can dig deeper,
this is the second time I see the
test_module.sh
script does not recognize a non working fan control. Somehow fails on the main task it should do 😞So generally we should check the following points:
From here try the following way:
dmesg
says, if you load the module usinginsmod asus_fan.ko
from within the build dir---please post what happens with and withoutforce-load=1
. (I also added some more debug, just now, no linux box here, so it's untested, will check it later, but "looks good" 😄 ) (this will hopefully tell us what is happening under the hood)dmesg
output we see) or should play withacpi_call
using your link this at least will hopefully show which ACPI paths are existing/working, please check this comment here in the other issue, generally we only have to test:It is very likely that if any of those is missing or so, loading the module might fail. If you find out which one this is, I could work around this in the init phase (and/or exclude it completely). Depending on which one this is, we then also have to find the replacement to get full functionality for
asus_fan
.The text was updated successfully, but these errors were encountered: