Hacker News Reader

Comment by 2muchcoffeeman | Hacker News Reader

I can live without the fingerprint reader.

It’s the lack of hibernate that really sucks. I got my 2013 MBA battery replaced. Leave it unplugged for 10 hours. 1% battery drop.

XPS 17 on Pop OS LTS with kernel 5.8. I have to shut down if I want battery left.

View on HN

On XPS 13 (2017) I watched this break due to a firmware update from Dell (something to do with sleep states)

Before the update: Windows sleep was strange, it would sleep but drain battery like crazy. Linux sleep was perfect, I could have the laptop sleeping for days.

After the update: Linux sleep started showing the exact problem as Windows now.

I did not dive much further because I switched jobs and got a ThinkPad at the new one which works perfect.

Windows/MS was the people behind the mess Todo with bios sleep states and lack of support in Linux. That was resolved ages ago though.

> I can live without the fingerprint reader.

Semi on topic: I don't have one either but I would really like to, simply because then I could have a stronger account password.

Having to frequently use sudo restricts the length/complexity of the password since a longer one would simply be a pain in the ass to use. With a fingerprint reader this problem wouldn't exist.

Had the same problem with mine. You need to change the sleep mode. You need to change sleep to mem_sleep_default=deep

I found it much more difficult. I had to move my swap partition into the LUKS partition so it was encrypted, resize it to be much bigger than the default then figure our how to have the RESUME=disk-uuid boot flag enabled for EFI boot. I got it working but it was quite time consuming.

This was the method I found but it didn’t work for me and I gave up.

We see that kind of issue frequently and in the majority of cases it is not a Linux fault, but manufacturer firmware.

It is such a frequent issue I wrote an article 10 years ago that is still extremely relevant with simple instructions to enable a kernel work-around [0].

Specifically the problem is the ACPI DSDT (Differentiated System Description Table) - which is actually byte-code installed by the device manufacturer (but executed by the host OS) that handles device power states and enablement.

The problem is almost always DSDT methods are written to conditionally configure system hardware optimally ONLY when the host OS is a version of Windows as declared by the host OS's ACPI OSI (Operating System Identification).

When Linux boots only a minimal configuration is applied which very often has never been tested and thus devices fail to work reliably, especially for suspend/resume, in interesting ways.

Fortunately, Linux has a WORKAROUND that allows passing a 'fake' OSI on the kernel command-line in the form:

  acpi_osi=! "acpi_osi=Windows XXXX"

The first instance (=!) clears all built-in kernel OSIs to avoid confusion. The second string sets the 'best' and only OSI value which has been found in the DSDT of that PC.

That can be discovered from a Linux boot using:

  sudo strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort

E.g: on my Lenovo E495 (AMD Ryzen 7 3700U) I have:

  Microsoft Windows NT
  Windows 2001
  Windows 2001.1
  Windows 2001 SP1
  Windows 2001 SP2
  Windows 2001 SP3
  Windows 2006
  Windows 2006 SP1
  Windows 2009
  Windows 2009
  Windows 2012
  Windows 2013
  Windows 2015
  Windows 2015
  Windows 2016

So, on the basis that "Windows 2016" is the 'latest' and likely the OSI expected to enable all features optimally I use that. On Debian/Ubuntu I therefore have:

  /etc/default/grub.d/local.cfg

  GRUB_CMDLINE_LINUX="acpi_osi=! \"acpi_osi=Windows 2016\" "

Notice the escaped quote-marks inside the shell string since the argument contains a space.

(some folks might prefer to edit the package-shipped /etc/default/grub but I prefer to leave that virgin to avoid package-upgrade prompts when that file is replaced.)

After:

  sudo update-grub

  /boot/grub/grub.cfg

will have the acpi_osi= entries added to all the "linux ..." command lines

E.g:

  $ grep acpi_osi= /boot/grub/grub.cfg
  linux   /vmlinuz-5.12.0-rc5+ root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 2016" systemd.unified_cgroup_hierarchy=1 nosplash

[0] https://iam.tj/prototype/enhancements/Windows-acpi_osi.html

Pop OS doesn’t use grub :(

This is a kernel parameter, so just set it in whatever bootloader Pop OS uses..

Ok. Linux 5.10 actually seemed to improve the power issue but my sound and mic breaks which I need for meetings.

That sounds out of date. Linux has reported itself as Windows via ACPI OSI and actually reports FALSE for "Linux" OSI query for well over a decade now.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

https://www.kernel.org/doc/Documentation/firmware-guide/acpi...

most features of my laptop don't work reliably (MSI GS65) if I don't use the acpi_osi line, why would that be in that case ? I'm on archlinux with pretty much always the latest kernel

As mentioned by AnssiH, this hasn't been true for a long time - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... was merged in 2007. I wrote up the reasoning back in 2008 at https://mjg59.livejournal.com/85923.html, but since then Linux should always have been behaving identically to the most recent version of Windows as far as OSI responses go.

most features of my laptop don't work reliably (MSI GS65) if I don't use the acpi_osi line, why would that be in that case ? I'm on archlinux with pretty much always the latest kernel

What argument are you providing? In some cases if you pretend to be an older version of Windows then things will work better, since it's possible for the kernel to end up pretending to be a new version of Windows without all the relevant semantic changes in the drivers having been made.

No, I have to set it to the latest version (I think? I have acpi_osi="Windows 2019") for things to work correctly

Which kernel version are you running? That string was added in 5.4.

5.11

Ok. It should make literally zero difference in that case. What problems do you see without it, and could you mail me dmesg for both cases? (mjgarrett59@googlemail.com)

Just tried this on my AMD laptop with an American megatrends bios and it won't boot at all - just freezes while initializing the efi framebuffer device.

Clearly in some cases the manufacturers overrides for Linux are required...

Reply on news.ycombinator.com