If you thought the last couple of posts were a little low level, you may wish to avert your eyes. If acpidump is your thing, read-on. If you want to hear of my struggle with a consumer electronics companies customer support? This is for you.
So, recently have aquired a pair of fairly expensive laptops (Asus ux490 and Asus UX370). The ux490 is 4C8T w/ 16GB of ram, and rocks. The UX370 is a pretty thin convertible, 2C4T w/ 16GB ram. They are pretty decent hardware.
Nice and light, fast, etc. Great. But, close the lid and next day you don’t have much battery left. Which is kind of sad and kind of a pain. They use about 25% in 8-hours of sleep.
So, I opened a support ticket w/ Asus. In the chat window they immediately tried to blame me, and then closed it saying I was running Linux and would damage the laptop, no warranty. Infuriated I asked to escalate and got a call back from a decent conciliatory chap who went through the same script. If it is not the windows we installed, go away.
I pointed out I was not complaining about the time that the OS *was* running, I was complaining about the time it was *not* running.
I asked to just get the spec for how much power draw to expect overnight in sleep for their reference Windows. Surely that would be ok? He allowed it would and escalated it to the Engineering team. They responded the next day saying:
We are happy to help you resolve your issue by providing you with the best possible solution. We would like to advise you that we do not have that information as the we do not support Linux based operating systems.
I’m sure it made them happy. All it would have taken is to say “we expect a loss of X% overnight” and I would have given up.
OK, now mad, and undeterred, and armed w/ a decent knowledge of embedded hardware and dram refresh methodology, I decided to get even. And this is what I found (and the fix for those of you with similar situation).
First, a primer. Intel has a whole series of power states (P-states, S-states, C-states). I won’t go through these here, but the one I want to be using is called ‘S3’. This is the lowest power mode before things are flushed to disk and power is off (S4 or hibernate). I cannot use hibernate since I use UEFI secureboot (and this would mean signing the swap on hibernate). So S3 it is. Are we using it?
My first thought was to remove the panel and put a meter on the battery while it slept. But then I thought, there must be a better way. And lo, here it is.
cat /sys/power/mem_sleep [s2idle] deep
OK, so this means I am choosing ‘turn the led off and hope the user thinks this is low power’ instead of ‘turn CPU off and let ram self-refresh’ mode.
To fix temporarily, we can echo deep > /sys/power/mem_sleep
To fix permanently we can add ‘mem_sleep_default=deep’ to /etc/default/grub and update-grub
OK, so why?
Well, it turns out, as I suggested, they have a bug in their BIOS. It tells the OS to use this mode:
acpidump > foo acpixtract -sFACP foo iasl -d facp.dat
looking in facp.dsl, we see that
Low Power S0 Idle (V5) : 1
which I (?) think means the kernel is told by the bios that the best low power mode is S0
rather than S3.
But, who am i to understand the quirks of a BIOS. And why on earth would a company I’ve just spent $5K with let me help them make their product better? Its way easier to assume my head is filled with dead insects and that I’ve inadvertently bathed the product in battery acid. Geez. Each time I tried to suggest the specifics of a BIOS issue they responded with “Its your fault for running Linux”. I have to believe this will behave the same with Windows since its in the ACPI table in the BIOS, but whatever.
Leave a Reply