Asus Zenbook UX31E powers off on plugin in/out AC adapter

Bug #989191 reported by Janne Savikko on 2012-04-26
78
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Linux
Unknown
Unknown
linux (Ubuntu)
Medium
TJ

Bug Description

When I have logged in to Unity and plug in or out AC adapter to Asus Zenbook UX31E, computer powers off. Sometimes this needs couple of tries (waiting or not waiting in between) when plugin in or out AC adapter.

This problem doesn't occur when I have switched to console or when in LightDM login screen. Problem doesn't happen with MS Windows either.
And yes, there's enough power in my battery too, I can boot up and use the computer without AC adapter.

syslog prints these lines to stdout in console, when plugin AC adapter first out and then in:
  [ 869.521396] asus_wmi: Unknown key 57 pressed
  [ 874.704525] asus_wmi: Unknown key 58 pressed
  [ 876.993295] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

What you also need:

1) lsb_release -rd
  Description: Ubuntu 12.04 LTS
  Release: 12.04

2) I could guess kernel, but it happens _only_ when I have logged in to Unity (or Unity 2D)...

3) I expect that my computer doesn't power off.

4) Computer powers off.

Janne Savikko (jsavikko) on 2012-04-26
description: updated
affects: ubuntu → linux (Ubuntu)
tags: removed: ac-adapter asus unity

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 989191

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: precise
Janne Savikko (jsavikko) wrote :

Hi,

I'm unable to run 'apport-collect 989191' (No packages found matching linux).

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Joseph Salisbury (jsalisbury) wrote :

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-rc4-precise/

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
tags: added: needs-upstream-testing
Janne Savikko (jsavikko) wrote :

Upstream kernel "linux-image-3.4.0-030400rc4-generic" fixes the problem.

apt-cache policy linux-image-3.4.0-030400rc4-generic
linux-image-3.4.0-030400rc4-generic:
  Installed: 3.4.0-030400rc4.201204230908
  Candidate: 3.4.0-030400rc4.201204230908
  Version table:
 *** 3.4.0-030400rc4.201204230908 0
        100 /var/lib/dpkg/status

tags: added: kernel-fixed-upstream
removed: needs-upstream-testing
Janne Savikko (jsavikko) on 2012-04-26
Changed in linux (Ubuntu):
status: Incomplete → Opinion
status: Opinion → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Fernanda Weiden (fernanda) wrote :

Hi all,
I had the same issue with my UX21E, I updated the kernel as suggested i this bug but the problem still occurs.

Please let me know which information you need from me to help debugging this issue.

Cheers,
nanda

Paul Smedley (paul-smedley) wrote :

I see the same here occasionally with my UX31 with Ubuntu 12.04LTS and the 3.5.13 kernel.

I've now updated to Ubuntu 12.10 beta and will see how I go. It's definitely somewhat random in nature...

Jafar Calley (jafar-3) wrote :

I have the same problem.

jafar@anachronos:~$ lsb_release -rd
Description: Ubuntu 12.10
Release: 12.10

jafar@anachronos:~$ uname -ar
Linux anachronos 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

The problem only occurs when logged in to Unity. I can unplug without shutdown by switching to tty console first, unplugging, then switching back to unity after. The same when plugging back in after being on battery.

hseffler (hseffler) wrote :

This bug is still present in 12.10.

Stefan Müller (smu-blackbox) wrote :

I have now added the line acpi_os_name='Microsoft Windows XP' to my kernel boot options. Seems I can pull the cable without crash now. Don't know how long this will last. If required, I can post a log of ACPI error messages I still see when using dmesg | grep ACPI.

Stefan Müller (smu-blackbox) wrote :

After running in battery mode for about 5h the system shut down without warning. First time while surfing the net and afterwards while restarting the system. Remaining battery life reported: 1:36h. So the problem still occurs.

 Attached is the output of running "dmesg | grep ACPI". I don't know what these errors mean reported there or what to do about it. Maybe someone at Ubuntu will send this to someone having a clue.

Stefan Müller (smu-blackbox) wrote :

@hseffler/jaffar:

Possibly you could try this kernel line:

quiet splash drm.vblankoffdelay=1 i915.semaphores=1 i915.powersave=1 i915.i915_enable_rc6=1 acpi_os_name='Microsoft Windows XP'

My machine runs quite stable now. I am using custom compiled kernel 3.6.7 (using default ubuntu settings for .config). The machine runs with laptop-mode enabled. Battery life time reported is about 7h but this seems to high. I would say the crash I reported before is due to a wrong report battery lifetime (don't know if this would be visible in the log?).

mx80 (rzach) wrote :

The kernel options given by @smu-blackbox made this problem go away for me. I then tried to figure out which of the kernel options I had before may have caused the problem, but I couldn't make the problem come back. My originaloption line was

quiet splash drm.vblankoffdelay=1 i915.semaphores=1 i915.powersave=1

Running 12.10 kernel 3.5.0-22-generic #33-Ubuntu SMP Wed Jan 2 21:47:30 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

mx80 (rzach) wrote :

Hmm, maybe I jinxed it?

I was trying to debug another issue (power off on ow battery: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1096498) and followed the instructions at https://wiki.ubuntu.com/DebuggingGNOMEPowerManager and did

$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"

I can unplug and replug before i do that, but when that command's running, it reliably crashes/powers the machine down. I've gotten it to hang once or twice. When it doesn't crash, it also doesn't produce any output past the very first message, which is:

signal sender=org.freedesktop.DBus -> dest=:1.95 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.95"

running latest BIOS 214 and kernel as above.

mx80 (rzach) wrote :

Ok, it also powers off without dbus-monitor running. But less often.

mx80 (rzach) wrote :

looks like it's fixed in kernel 3.8.0-030800rc2-generic #201301022235 SMP Thu Jan 3 03:36:23 UTC 2013 x86_64

Stefan Müller (smu-blackbox) wrote :

As the problem occurred again in 12.04 with all kinds of kernels released by Ubuntu (also with the 3.5-series). I tried 3.8.0. It still occurs now. Being logged in or not - does not matter. Meanwhile it also occurs when being in BIOS after the machine crashed in Linux before. The kerne starts with this crash dump parameter so maybe someone want to have a look at this? Where do I find this dump (if there is one - I doubt there is time to write a dump).

I confirm, it still occurs! Please give us a fix! :(

i could manage to minimize it by reflashing bios and choosing restore settings on bios menu (restart and press f2), it still crashes when temperature gets too high.

Gregor Kappler (g-kappler) wrote :

I confirm, this also occurs with my zenbook. It crashes most frequently when Video is running or during Skype conversations.
Linux alcedo 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:30 UTC 2013 i686 i686 i686 GNU/Linux

Janne Savikko (jsavikko) wrote :

I don't think this is a software related problem but hardware one. I've been running Windows on my ZenBook lately, and this problem occurs with Windows too. Usually I see it when the laptop is running hot and I try to plug or unplug the power adapter, but I can see it sometimes too when I've just restarted the laptop.

And for me this has gotten more common lately. It's not a problem with battery running old, because battery can hold power about 4 hours. I'm not familiar how switching between power adapter and battery modes work, but could it be a problem with capacitors?

Anyway, I'm taking my laptop to retailer for a repair.

Janne Savikko (jsavikko) wrote :

Forgot to mention:
Could someone with the problem try reproducing it with Windows? Or (if you're not converted all of your friends to linux) ask from a friend who's running Windows in her/his Zenbook UX31E.

Oleksij Rempel (olerem) wrote :

Just to notice,
i have this notebook too. This hardware was affected by USB suspend bug. One common thing on it is that this laptop can go down in misconfigured state. After power on it will stay misconfigured intill it will be configured and power down properly.

So, if you compare different settings, try to power down and power up with this setting before actuall test. If you do not do this, your test will drive you creasy. With windows it is not reproducable untill you start to use linux.

Oleksij Rempel (olerem) wrote :

hm... can some one confirm this test:
sudo stop acpid
sudo pkill upowerd

now try to plug or unplug AC adapter. Is this crash still reproducible by you.
Please notice. If you will click on battery status icon upowerd will restart automatically. So, do not touch it.

Jussi Palomäki (jmmpal) wrote :

"Could someone with the problem try reproducing it with Windows?"

I reproduced the problem with Windows 7. Here's my test setting:

I reinstalled Windows 7 and some drivers and utilities (most importantly ASUS Power4Gear-Hybrid) from here:

http://www.notebook-driver.com/fi/asus/asus-zenbook-ux31e-win7-64bit-driver-utility/

First I didn' t get any crashes (same goes always some time with fresh install of Ubuntu). I tried to pull AC-cable off every now and then and with different amounts battery charge.

I used Jpcsp as test application (because it uses lots of resources, and always freezes Ubuntu if I try to run it without AC-cable). I didn't get any crashes, but I noticed that the emulator slows down every time I pull off the AC-cable, so I went to check Power options.

I found out that in On Battery -mode in ASUS Power4Gear-Hybrid's "High Performance"-battery plan the maximum processor state is set to 80% as default. I changed it to 100% (AC not connected, emulator still running) and immediately got the shutdown. After restarting I tried Windows 7's own High performance setting (maximum processor state 100%; I had to force ASUS Power4Gear-Hybrid to shut down before that, because it tries to overrun the battery plan every time I touch the AC cable). When I started the emulator (AC still not connected), Windows 7 froze. In that point I had only 30% of battery charge left. When I tried to restart Windows 7, I got immediate shutdown (probably because of low battery). Then I put AC cable back on, waited for some time for battery to charge and ran the emulator again (with about 50% charge). Everything worked untill I pulled AC cable off -> crash. I changed maximum processor state back to 80% and ran the emulator again. When I pulled off the AC cable, I didn't get crash. I repeated this about 10 times and still no crahes. Here's my conclusion:

The shutdown or freezing occurs in Windows 7 when:
- Processor state is over 80% and the AC cable is pulled off
- Processor state is over 80% and the AC cable is not connected
- Processor state reaches some point that's more than is needed to run grub but less than is needed to boot Windows 7, the AC cable is not connected and battery has less than 30% of charge

After I wrote this my heart was pounding when I last time pulled the AC cable off (Power4Gear-Hybrid's default "High Performance"-battery plan is currently active). As you can read this, you can see that I still didn't have any crash.

Oleksij Rempel (olerem) wrote :

Hi Jossi,

for some weeks now, i did fresh windows install to recheck this issue. Then, after i was able to get crash in widnwos i was ready to send it RMA as defect. But decided to do last check: i did asus update (there was some tools, but no bios update). And i unplugged buttery (this laptop has some bugs which will survive reboot). After this, i was _not_ able to reproduce this bug again.
Well, i didn't tested your reproduction case...

If you can reproduce it can you please reopen a this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=60812

Jussi Palomäki (jmmpal) wrote :

Hi Oleksij,

thanks for the hint. I installed and ran ASUS Live Update. It installed 2 components: ASUS Live Update v 3.1.9 and Fresco USB3.0 Driver v 3.5.4.0. I also did Windows 7 update (110 different updates, mostly security related). After updates I repeated the tests I mentioned above.

Running Jpcsp on battery with maximum processor state set to 100% (with 87% charge) didn't cause crash. I repeated the test (84% charge) and didn't get crash. I put AC cable back on and forced max processor state to stay at 100%. I pulled AC cable off and didn't get crash.

But there are two things. I ran Jpcsp simultaneously with system monitor and now CPU usage was all the time under 50%. Maybe the updates did something to reduce CPU usage? I need to do more tests and for that I need heavier application than Jpcsp, to test if heavier CPU usage still causes crash. I also need to repeat the original test with lower battery charge, since it seems that there might be a trend towards less stable Windows 7 when battery charge is lower.

Jussi Palomäki (jmmpal) wrote :

Hi guys, here's my final report:

I managed to reproduce the problem even after installing ASUS Live update, even with smaller CPU usage. Key thing was to put more files to SSD (the problem came back, when SSD usage reached about 50 GB). So it seems both the CPU and SSD usage affect the stability. This was 3 weeks ago. I didn't post this earlier because I wanted to try to unplug the battery first, as Oleksij suggested. The most difficult part of this testing was to find a torx T5 screwdriver - seriously, the smallest I was able to find in Turku was T7! Fortunately my brother had one so when I visited him two weeks ago I was finally able to open my laptop and try this one last thing.

All crashing stopped completely after I opened my laptop and ***unplugged the battery***. I have so far tested this with Windows 7, Ubuntu 13.04 and 13.10, forced CPU usage to stay at 100% and filled my SSD up to 80% with 3 partitions (FAT32, NTFS and Ext4). Not a single crash in 2 weeks!

I believe mine was actually a memory controller related problem that was originally caused by a bug in Ubuntu 11.10:

https://help.ubuntu.com/community/AsusZenbook#Suspend

Feels pretty stupid that I didn't try this 1½ years ago... maybe I was just too afraid of losing warranty (and I didn't find a suitable screwdriver) or something. But now everything works fine.

I hope this helps.

Chonnawonga (brad-meredith) wrote :

Jussi, thanks for your helpful comments. Yes, this is definitely a product of that old memory controller problem. If you're experiencing this bug, the only solution is to find a torx T5, open the case, and disconnect the battery for a moment. This is a hardware problem more than it is a software problem.

Opening the case is fairly easy. There is a useful description with pictures here: http://www.ski-epic.com/2012_asus_zenbook_ux31_disassembly_teardown/

You don't have to remove the battery. Just pull straight up on the connector to the mainboard. There's a helpful little black pull tab for this.

Good luck, everyone!

Janne Savikko, 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.12

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.

tags: added: needs-kernel-logs needs-upstream-testing
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Timo Hülsmann (thuelsmann82) wrote :

Unplugging the battery solved this issue for me, too. Thx to Jossi!

Janne Savikko (jsavikko) wrote :

Christopher M. Penalver (penalvch) wrote on 2013-11-17: #31
> Janne Savikko, 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?
>

Hi Christopher. Unfortunately I can not test this issue anymore, because I got an other model from retailer because of hardware problems.

I too was running Ubuntu 11.10 before upgrade to 12.04, so as Jussi Palomäki wrote, this problem seems to be related to memory controller and was revealed when using old kernel.

Jussi Palomäki (jmmpal) wrote on 2013-10-26:
> I believe mine was actually a memory controller related problem that was originally caused by a bug in Ubuntu 11.10:
> https://help.ubuntu.com/community/AsusZenbook#Suspend

At least there seems to be a workaround available: open the case and unplug the battery.

Janne Savikko (jsavikko) wrote :

Fix released: "PCI: EHCI: fix crash during suspend on ASUS computers" https://github.com/torvalds/linux/commit/dbf0e4c7257f8d684ec1a3c919853464293de66e

Changed in linux (Ubuntu):
status: Incomplete → Fix Released
fatima (fatima-fb1988) wrote :

I have the same problem in Win 8, with my Zenbook UX21E . Are you sure unplug and plug the Battery will solve the problem? No need to updating risky Bios?

TJ (tj) wrote :

Returning status to Triaged since there are multiple reports that this issue is not fixed, and commit dbf0e4c7257f8d6 referred to in comment #34 is a USB suspend/resume issue, not a power-profile when on battery issue.

Changed in linux (Ubuntu):
status: Fix Released → Triaged
TJ (tj) wrote :

There are several reports that the model works fine as far back as 12.04

However, there are several confirmed reports that disconnecting the internal battery and/or re-insulating its leads, solves the issue. That suggests a power starvation issue, or that some component remains powered when the PC is shutdown and therefore never does a cold reset.

TJ (tj) wrote :

Useful investigation and follow-up comments from Matthew Garrett's at his site:

http://mjg59.dreamwidth.org/11750.html

Several users confirm opening the case and disconnecting the battery for a short time (a couple of minutes) and reconnecting appears to permanently resolve the issue.

sclimans (sclimans) wrote :

My ACPDI Dump after a corrupted hard drive from this issue.

TJ (tj) wrote :

Feedback and discussion with sclimans on IRC #ubuntu suggests that the battery disconnect 'trick' does solve the problem for a while, but one or maybe more suspend/resume cycles causes it to recur.

That tends to suggest that the UHCI fix of writing 0 to the PCI command register at suspend might be required for other PCI devices.

Changed in linux (Ubuntu):
status: Triaged → In Progress
assignee: nobody → TJ (tj)
Simon (eierfrucht) wrote :

=========================================================================================

Finally, a reliable solution for unexpected shutdowns and hangs was discovered!

This seems to be working with any Asus laptop suffering from unexpected shutdowns and / or hangs while running on battery:

1. Add the following boot arguments _both_ to GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX in /etc/default/grub.cfg:

intel_pstate=disable pcie_aspm=force acpi_osi=’Windows 2009′ acpi_os_name=’Windows 2009′

Don’t forget to execute sudo update-grub afterwards!

2. Install the package tlp from ppa:linrunner/tlp an set at least the following values in /etc/default/tlp

CPU_SCALING_GOVERNOR_ON_BAT=ondemand

CPU_BOOST_ON_BAT=0

PCIE_ASPM_ON_BAT=powersave

RUNTIME_PM_ON_BAT=on

3. Shut down the device, carefully remove the bottom cover and detach the big battery (not the tiny CMOS battery) from the motherboard for five minutes. There are plenty of youtube videos showing how to safely disassemble the various Asus laptops. With certain power management settings on the OS side, the EC (Embedded Controller) goes crazy and thus needs resetting. The only way to reset it is to detach the battery for a few minutes.

4. From now on, shutdowns should be gone. Take care, however, not to _ever_ use any live USB stick or installation / recovery CDs based on Linux and using the intel_pstate driver and / or the default BIOS settings for ASPM. If you try to, you will merely reproduce the problem once again, and will subsequently have to disassemble your Zenbook once again. There are a few sad cases, like reinstalling Ubuntu itself, where you will _have_ to boot from a live USB utilizing the problematic intel_pstate driver. Only do so when running on AC, and please repeat Stage 3 (no matter how boring) of this manual once you are done.

P.S. Intel_pstate and the default ASPM bios settings eventually make the mobo’s Embedded Controller go crazy and persist in this state until the battery is detached from the motherboard. That’s basically how this problem is born.

sclimans (sclimans) wrote :

Simon, thanks for the suggestions, but they unfortunately did not work for me. I am running Ubuntu 14.04 on an ASUS Ux21 Series Ultra Slim. This bug has been an issue for me since getting this laptop. It is no longer a laptop as a result of the bug—I am forced to use it only when plugged in.

The suggested solution above did NOT work for me. I followed the steps exactly as described (included unplugging the battery for five minutes) but when I restarted the computer and then tried unplugging my laptop, the computer crashed and shut down immediately. The only possible difference I note between your setup and mine is that my grub file does not have a ".cfg" suffix.

Simon (eierfrucht) wrote :
Download full text (3.3 KiB)

I have a regular UX21E. I am using a modified BIOS (rev. 214) and a custom DSDT table. I could modify your BIOS and make you a fixed DSDT, but that poses a risk of bricking the device. I could send you instructions to modify it on your own as well.

There's nothing 'criminal' in the vanilla DSDT of my UX21E, it just has a few dozen non-critical errors which is quite normal for an ASUS device. I just corrected them and forced a Windows 7 signature so, regardless of the operating sytem actually installed, ACPI employs preferences optimized for Windows 7 (UX21E is officially stated to work ONLY with Windows 7, so I was having suspicions that a different, and maybe actually broken, set of ACPI preferences was used because I simply don't know how Ubuntu introduces itself to the BIOS -- except for the fact that it never declares itself Linux for compatibility purposes) Specifying the lines 'Windows 2009' acpi_os_name=’Windows 2009' in the grub command line should work to the same effect. Please note that the ' symbol is sometimes rendered incorrently on this site, so plain copy-pasting from the web page may fail to work.

As for my custom BIOS, I simply used the AMIBCP utility to unhide a number of hidden BIOS options, then used the UBU utility (ver. 1.37) to update the CPU microcode. Then I flashed the modified BIOS with AFUDOS and played around with the hidden BIOS settings a bit. I enforced Native PCI-E control and Native ASPM (this is designed for newer OSes like Windows 7 and later and enables the OS to reconfigure ASPM in all sorts of ways) However, it seems that putting the 'aspm_pcie=force' in the grub command line should work to the same effect, 'sudo tlp-stat' should say that a 'powersave', not a 'bios defaults' ASPM policy is engaged.

I also fully disabled Sandy Bridge Turbo Boost (also achievable with CPU_BOOST_ON_BAT=0 in the TLP config) and changed a few other default BIOS settings, none of which seemed to share any direct connection to the problem.

Finally, I updated my Intel Management Engine firmware using a DOS live USB stick. Intel ME lives inside the same flash chip that contains the BIOS, however it is not affected by any BIOS updates. It utilizes a different region of the flash memory which never gets touched during a BIOS update.

What you are experiening reminds me of a well-known problem of many Zenbooks: highest tolerable CPU temperature is different for BAT and AC modes. A hot CPU will switch off automatically as soon as the device enters battery mode. This issue was fixed in the latest BIOS revision for all Zenbooks. But maybe you need to reset CMOS (i.e. unplug that really super tiny CMOS battery) for this kind of change to kick in.

If it's not the case, please post a link to the latest official BIOS for your device on the ASUS site. Maybe the UX21 Ultra Slim you are talking about is exactly the same thing as my UX21E and you could use my BIOS and DSDT tables.

Also check the output of 'sudo tlp-stat', if there is a really huge difference between 'energy_full_design' and 'energy_full' values in the battery stats, you just happen to have a bad battery. Even for a badly worn out battery, the difference shouldn't be abo...

Read more...

Mcafee Support (mcafeesupport) wrote :

Thanks for the information about the bug. It will useful for the Asus users. Kindly update us when a bug is found in another brand laptop also.
<a href="http://supportnumbers.net/mcafee-support /">Mcafee Support</a>

very interesting post and I really enjoyed a lot and I found many interesting posts on your website thanks for sharing if you have any query related to McAfee support so contact us we are providing best support service with the best solution <a href="https://mcafeesupports.org/mcafee-activation-errors-and-solutions/"> McAfee Customer Service</a>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.