desktop-packages team mailing list archive

[Simon <eierfrucht@xxxxxxxxx>]

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 Desktop
Packages, which is subscribed to xorg in 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

Status in xorg package in Ubuntu:
  Incomplete

Bug description:
  SUMMARY: On the ASUS UX21E ultrabook, enabling SNA graphics
  acceleration leads to spontaneous shutdowns while watching Flash video
  in full screen AND using the battery as the power source, the problem
  starts surfacing once the battery charge level drops below 33%. The
  issue affects both x86 and x64 platforms, affects at least the 14.04
  and 14.10 Ubuntu versions, affects at least the regular Ubuntu and its
  Kubuntu and Lubuntu flavors, affects at least kernels 3.13, 3.14,
  3.15, 3.16, 3.17, 3.18, 3.19 and 4.0. The issue can't be fixed by
  changing the various i915 driver options like rc6 and semaphores,
  neither does PCIE_ASPM play a role. Repetitive triggering of the bug
  runs the machine into an even weirder state where it would chaotically
  reboot every time a higher-than-moderate strain is put on the GPU, and
  the only way to fix this is to detach both battery connectors from the
  motherboard for a while (CMOS battery and the main power source
  battery) The issue surprisingly disappears after a hard CMOS reset AND
  setting the acceleration method to UXA. The BIOS version of my UX21E
  is 214.  I've also taken my UX21 to the official ASUS service center
  and after running the tests they replied that the unit has no hardware
  issues, so it is a Linux issue. A vaguely similar issue is reported to
  affect UX21E running Windows 8, so it may be a crippled DSDT after
  all.

  THE LONG STORY:

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

  IMPORTANT UPDATE! As of 14.04 and 14.10 using the default SNA graphics
  acceleration instead of UXA leads to unexpected shutdowns and/or CMOS
  settings corruption. To activate the bug, one must be:

  -- Using the battery as the power source

  -- Having the battery charge below 33%

  -- Watching a FULLSCREEN video in Flash Player (e.g. youtube)

  -- Both Pepper Flash in Chrome/Chromium and the regular Adobe Flash in
  Firefox/Chromium are affected

  This is the most typical scenario for triggering an unexpected
  shutdown, but other variants do exist. Certain Flash-heavy sites like
  speedtest.net can trigger this, as well as KDE's KWin window
  compositor with certain GLX-accelerated eye candy options turned on.
  The bug also affects at least Kubuntu and Lubuntu, but that's just
  what I was able to confirm. Most likely it affects all other Ubuntu
  flavors and even other distributions that use the latest Intel video
  drivers AND employ SNA as the default acceleration method.

  The issue persists with various Ubuntu versions (at least 14.04 &
  14.10), various kernel versions (I tried almost every kernel from 3.13
  to 4.0) and even using the cutting-edge drivers from the xorg-edgers
  PPA does nothing to fix this. Both x86 and x64 platforms are affected.
  Flash Player version plays no role, either. The bug apparently happens
  because the ultrabook's ACPI-based power management mechanisms just
  can't get on terms with the latest implementation of SNA. Something
  happens when the battery charge drops below 1/3 -- and once SNA draws
  too much power from the GPU, a shutdown happens. The various i915.*
  driver options like rc6 and semaphores do nothing to fix this!

  The worst thing is that after you get several unexpected shutdowns,
  your UX21E may start rebooting chaotically whenever any program tries
  to use graphics acceleration, be it Chromium's accelerated canvas
  rendering or simply the window manager using transparency. This
  further leads to file system corruption up to the point when you can
  no longer boot into your user profile. You can still create another
  user profile via the terminal, but this does not get rid of the reboot
  glitch.

  If you happen to run into this, you must perform a hard CMOS reset. To
  do this, one must unscrew the twelve torx screws and remove the bottom
  part of the casing, then detach *BOTH* the main battery connector and
  the CMOS battery connector from the motherboard, then wait for a few
  minutes and attach them back. Flushing CMOS programmatically with a
  command-line utility like CmosPwd does not fix this issue! If you are
  unsure how to open your UX21E or detach the battery connectors, search
  youtube for an UX21E disassemby guide -- detaching the battery on this
  model used to be a popular trick a few years ago when a certain
  Windows glitch caused similar behavior and required hard CMOS reset as
  well, so there are a number of videos and forum threads on this issue
  across the web.

  Once you have made sure your CMOS is okay (that is, you don't get
  frequent shutdowns shortly after logging into the system while working
  on battery with a charge below 33%) you can proceed to fix the
  ultimate cause of this issue. If it exists, delete the
  /usr/share/X11/xorg.conf.d/20-intel.conf file then create a new one
  containing the following lines:

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Section "Device"

  Identifier "Intel Graphics"

  Driver "intel"

  Option "AccelMethod" "uxa"

  EndSection

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Reboot and the issue is fixed!

  I also recommend using the following kernel boot arguments with this
  model to provide maximum power saving and stability in 14.04 and
  14.10:

  intel_pstate=enable pcie_aspm=force pcie_aspm.policy=default
  ath9k.ps_enable=1 i915.semaphores=1 i915.enable_rc6=7 i915.powersave=1
  i915.lvds_downclock=1 drm.vblankoffdelay=1 i915.enable_fbc=1

  Enabling 'i915.enable_fbc' and 'i915.lvds_downclock' can lead to minor
  graphical glitches with SNA acceleration, but since SNA is a no go due
  to the above mentioned bug, you can safely turn them on with UXA.
  'pcie_aspm' absolutely needs being set to 'force' and
  'pcie_aspm.policy' to 'default' -- the UX21E is very picky about this
  as of the latest official kernels in 14.04 and 14.10.
  'ath9k.ps_enable' is required to enable wireless power saving in power
  managing software like TLP

  I hope someone re-formats my remarks to fit into the article in a more
  befitting manner and/or files a bug on the Ubuntu bug tracker because
  I'm almost exhausted and broken while typing this. Tracking this
  sucker down cost me almost two months of my life because once you run
  into the chaotic reboot issue, you can't fix anything without hard
  resetting the CMOS, and it took me too long to realize.

  Thanks for understanding.

  P.S. This may also affect other Asus ultrabooks with integrated Intel
  graphics like UX31E. A Windows bug with very similar symptoms is known
  to affect the whole model line, especially with Windows 8.1

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1446027/+subscriptions