I'll be able to do it some time before Monday. Sorry for not doing so right away.
Meanwhile, bad news. This behavior is by design. Running custom microcode and setting rc6 to 5 does not fix the issue, it's just an ugly workaround. One thing I've been missing all these weeks which I discovered about three hours ago: When /sys/class/power_supply/BAT0/energy_now drops below 7000 mW, /sys/class/power_supply/BAT0/power_now takes an instant dive from about 16000 mW to 12000 mW and at the same time, all CPU cores are throttled down to 800 Mhz. No kernel or BIOS setting seems to be able to circumvent this. Even pinning the minimum CPU frequency at 1200 Mhz via TLP only works until the battery charge keeps above 7000 mW. Then it's forcibly reduced to 800 Mhz. The boot flag acpi=off seemingly "fixes" this but quite expectedly breaks dozens of vital functions. If there's Flash Player running at the moment of throttling AND the current power consumption rate is high enough, a shutdown happens. Pinning the maximum CPU frequency at the same 800 Mhz while on battery does not help -- even if the frequency does not change, when the battery charge drops below the above mentioned threshold, the system may crash. If there's no Flash Player running (both Pepper and the regular Adobe Flash are affected), even a 100% CPU load does not result in a crash. If there's Flash Player running, but the power consumption rate at the moment is relatively low, there's no shutdown. Once the threshold is passed and the CPU is forcibly downclocked to 800 Mhz, I can watch as many Flash Videos in highest resolutions at 100% CPU load and... nothing happens. Almost anything that affects power consumption -- be it a custom-made CPU microcode, newer VBIOS, hidden BIOS options or simply a specific RC6 setting -- automatically affects the probability of shutdown. SNA acceleration spawns rather small but frequent peaks of power consumption, which kinda provoked the issue. Currently I experience no shutdowns with RC6=5 and a custom CPU microcode, but I'm inclined to think that it's a poor solution and there's still something terribly screwed up inside the UEFI BIOS. In understand this emergency throttling thing was meant, uh, as an emergency measure for a Windows-based environment to give the user as much time to save his work as possible. In Linux, it's just a pain in the butt. So, this bug needs reassignment. Now it looks more like a hardware quirk which begs for a workaround. So far we have: -- The bug is hardware-specific. It affects at least the UX21E Asus Zenbook. -- The cause of the bug is a low-level, BIOS-based service which uses ACPI to simultaneously downclock the CPU and reduces the battery power output once the battery charge drops below 7000 mW. -- For a shutdown to happen, a relatively high power consumption level and a running instance of Flash player must coincide at the moment when the forced downclock happens. Just having high CPU usage OR just running Flash isn't enough. -- Anything that affects power consumption does affect the probability of shutdown. Enabling features which result in power consumption peaks (even small ones) greatly increases the chances. Various power saving techniques play towards reducing the probability. SNA acceleration seems to be the most provoking factor. -- The issue affects a wide range of kernels at least from 3.13 to 4.1, i686 and amd64 versions are equally affected. Installing the cutting- edge Intel graphics drivers and xorg from the xorg-edgers PPA does not affect the frequency of shutdowns. At least Ubuntu, Lubuntu and Kubuntu are affected. P.S. I've just rolled back to the good old BIOS 214 (the latest official one) and checked -- this weird downclocking-when-on-low-battery feature is still there and it's official! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1446027 Title: SNA acceleration causes sudden shutdowns and corrupts CMOS data on the the Asus UX21E ultrabook on a wide variety of kernels since at least Ubuntu 14.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1446027/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
