Hacker News Reader

Comment by 1996 | Hacker News Reader

1996

This is short on details. So here are some more: since S0 ( active suspend) became more popular with windows 10, most manufacturers have decided to REMOVE THE CODE from the bios that allows S3 (suspend to ram).

Worst case is they left the stubs pretending S3 is supported, so the computer goes to sleep - but never wakes up! Dell, I'm looking at you!!

Workarounds come from redoing the S3 code, mostly in ACPI tables with triggers - for all peripherals.

It is a shame, as in S3 most laptops eat less that 1% of the battery per hour, while in S0 such good results require heavy configuration to prevent the "active" part of active sleep, and make sure the laptop never wakes up until you actually press on the power button. But I guess it is the road to progress, as S0 is more flexible.

View on HN

It's worrying how obscure and poor standards compliance modern hardware is starting to display. And we're talking about PCs. Let's not even discuss mobiles.

In 2012 I bought a MacBook Air to run Linux. It's a great silent machine with all Intel hardware, except the pretty poor quality Broadcom wireless card. It boots with any vanilla kernel, and everything just works. Except for poor wireless range. What machine can I buy these days that?

i) Just works on Linux (which in practice means everything has to be Intel, including the wireless card)

ii) Is reasonably silent

The only machine I've found worth considering is a Xiaomi Air 12 with a m3 (fanless) CPU. Some Thinkpads are OK, but they tend to be on the noisy side of things due to excessively small fans and too much power I don't need. This, despite aggressively tweaking powertop settings.

I'm also looking for external USB high-gain wireless antennas. But even classic Alfa ones with Atheros 9271 chipsets are a hit and miss.

It's a bit hopeless. If someone has good suggestions, I'd be glad to consider them.

> It's worrying how obscure and poor standards compliance modern hardware is starting to display.

The standards are too complex. I've spent thousands of dollars on ISO standards documents over the past several years.[1] The complexity of these documents is absurd. And I've never seen an implementation that came close to adhering to the entirety of the standard--everybody always takes shortcuts because it's not cost-effective otherwise. The problem is, everybody takes different shortcuts, so you end up with endless interoperability problems.

The exceptions are often when everybody sources hardware or software implementations from a single vendor. That's when things go more smoothly because everybody is using the same half-baked driver or firmware.

[1] The last document I purchased was 138CHF (coincidentally $138USD at today's exchange rate). They've always been at least that much in recent memory, and often standards are broken up into separate documents or incorporated by reference so you're paying 4x or 5x to get the entire standard. There's alot of free documentation online that open source developers often use, but personally I find it difficult to wrap my head around these things unless I have an idea of the overall design. (I want to see the overall picture so my initial API and architecture isn't a pile of technical debt from day 1.) I have the means so I bite the bullet. But it's a real loss to the entire community--and industry--that these standards aren't freely available. Quality of implementations would be so much better if standards were always open, and sunlight might help minimize the complexity of these things by exposing the flexibility demanded by proprietary vendors on the committees as useless barriers to entry.

Taking one example... UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. I don't have a solution to this problem to propose, other than to say, if you're in the position to influence specs that effect the design of hardware, or are the result of hardware design, please push for the simplest solution to the problem every chance you get. That said, huge amounts of complexity are added to things in the name of backwards compatibility, which is something we generally want.

In the case of the S3 sleep state, this is just sloppy decision making. Sure give us a new fancy, half sleep-like mode, but don't touch the suspend to ram, it's a feature that has value.

I can't disagree with you. But regarding backwards compatibility, the simpler the standard, the easer it is to write an implementation, the more practical it is to simply start fresh every iteration. Considering how cheap and disposable hardware is becoming these days, the more obvious is the false economy of flexibility in the design.

I don't do much traditional driver development (mostly USB related, at least when it comes to hardware). I know enough that dealing with the ARM ecosystem can be much more of a headache than in the PC world, for two reasons: diversity and more opaque specs. (Even if the PC stuff is proprietary, there's enough publicly leaked info to at least get started.) But ARM features are also often much simpler and straight-forward. If the documentation were always and completely freely available[1], then I think many developers would prefer dealing with ARM platforms than with PCs. You may be writing more drivers, but development would be more efficient and reliable and you could move on without having as much of a maintenance and bug-fix burden. It can be a worthwhile trade-off, and fits better with the open source model.

[1] I spent months trying to sign an NDA and gain access to NXP's iMX53 Security Reference Manual. After repeated back-and-forth with two NXP resellers, Mouser and Digi-Key, I just gave up.[2] I've heard of lone developers getting access to the manual, but they must be more familiar with the process than I am. Now I'm pivoting and have decided to use seL4 on PC hardware rather than bother with the TrustZone and the iMX53 crypto hardware, even though the ARM route would have been easier but for the documentation issue.

[2] I think it's NXP that kept dropping the ball, but I'm really not sure.

> UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right.

The culprit isn't UEFI, it's ACPI. That mess predates UEFI. Most operating systems don't really try to use UEFI features beyond the ability to manipulate the bootloader settings, and that feature is almost always correctly implemented. But it's impossible to find a consumer system with bug-free ACPI tables.

Is it a mess? The UEFI spec is big, but most of it is not necessary to boot.

The UEFI implementation in U-Boot is tiny, and yet is enough to boot (both from local storage and network) and have a text console.

Most non-embedded board vendors do not reimplement UEFI. There's not much to get right or wrong. They just take AMI or whoever's private fork of TianoCore, tweak some settings and customize the GUI. (It is possible to screw up the GUI though: https://youtu.be/F-ndTMeRT3s)

As mentioned in other comments, it's ACPI that's really bad.

Though at least it's a standard! On ARM, you typically have to have a driver for every. damn. power. controller. Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)

> Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)

I can't believe anyone would be thankful about ACPI. Is there a machine with ACPI that isn't broken in some way? My brand new Lenovo, which multiple sites have crowned the "best" PC laptop, ships with a LTE card that can't properly power down, and causes PCI-E ASPM to be disabled. Even Microsoft has f--ked up power management repeatedly in the Surface line.

Power management on PCs is such a disaster that it calls into question the very idea of doing power management for computers built out of mix-and-match components through standards like ACPI.

I dunno. I've worked with a bunch of different ARM chips and each one's workflow is "build a kernel, build an initrd, then use this magic tool to get our boot ROM to load it" and that's always been gross & dumb.

I'm not necessarily cheery about ACPI in practice, but ACPI & UEFI in theory provide some kind of substrate to manage the platform, that's not just whatever the engineers are some shop cooked up this time.

Thanks to Flattened Device Trees, you don't have to build special per device kernels, you can just have a generic kernel that includes drivers for all the SoCs.

But having individual drivers per SoC in the kernel for things like power management still sucks.

It would be easier if the specs were developed without the "help" of organizations that stand to gain nothing from complete interoperability and who are perfectly content with "works with Windows".

Thinkpads might not be as bad as you think. I have an X230 at home, which runs many flavors of linux extremely well and is dead silent, and a T440s at work which is also an excellent choice albeit slightly more expensive. You can pick up refurbished t440s'es for around 500-700 euros in the Netherlands, where X230's go for 200 at the very lowest price point (still with an ssd!).

Unless I'm playing Counter Strike on the X230, which runs great all things considered, I never ever hear the fan. Wireless and thankfully wired connections are spotless too, though the X230 doesn't have 802.11ac as far as I know.

The T440 is no longer being manufactured (the current model is T480). I have a refurb T460 at home[aside] which works great out of the box with any Linux distro and has a keyboard that is a pleasure to use when contrasted with most laptops out there. And the repairability also means that you can buy a cheaper model and only once you need it extend the sdd/ram when you need it.

[aside]: it has a top IO panel that every now an then decides to stop working, including the power button mouse and keyboard, although usb ports continue to work. The only option at that point is to hard reset (I carry a paper clip in my keychain :-/). Haven't found an explanation for the problem. If anyone here has any ideas, please reply. I've googled all around. I have found no correlation with anything so far.

X1 Carbon 5th gen had some kinks at first but has been serving me well w/ Ubuntu for a year now. Managing the HiDPI display has been the only real headache -- if I could go back in time I'd have gotten the 1080p screen instead of the high res one.

Besides that when I say it works, I mean it really works. Even the 4g card I added worked out of box on Ubuntu!

Yeah, that's why I got the 1080p screen :) Learned my lesson with the 2nd gen - that was a piece of crap.

HP Spectre x360. I run Arch Linux on it and everything has been fantastic.

Dell XPS 13. Comes with Linux and the new model is very quiet (fans don't even spin with most tasks).

Seconded. I have a 9360 and I've had everything work out of the box with Ubuntu 17.04, 17.10,and 18.04. As well as Linux Mint 18.3.

Only downsides are Linux's generally patchy support for hidpi, some programs scale and others don't (opt for 1080p version or set resolution to 1080p). And also the placement of the webcam is a bit strange.

Battery life is good in Ubuntu, between 6 and 10 hours depending on use case.

This is third degree price discrimination by Dell. I should have been more precise in my first comment.

To be crystal clear: the 9360 has a bios featuring the proper ACPI tables, which are omitted on purpose from other cheaper models, breaking S3 on purpose.

This is why injecting proper tables as proposed in this link restores normal functionality. It is not rocket science, just hard enough to do without proper documentation to be a waste of time.

The initial submission title said it was a shame, and I agree it is shameful to intentionally break features to charge higher price (and no, I won't buy that S0 works perfectly now, or that adding a simple if/else is "too complicated"

With cheaper models you mean non-XPS-13 models?

non developper models

Dell XPS runs linux flawlessly. Dunno about wireless range though

Dell XPS uses almost the same wifi as the macbook stuff AFAIK - the fullmac broadcom chips.

> tend to be on the noisy side of things due to excessively small fans and too much power I don't need

Huh. My X240 is so much quieter than my 2010 MacBook Air was.

The Air was... (I just realized this) very aptly named, as the volume of air its fans push is ridiculous.

Two years ago, I bought a ASUS ZENBOOK UX305FA and it is fanless and works well under Linux. Maybe there is some newer similar model.

I own Xiaomi laptop you mention for almost a year now (2016 model). It is overall a pretty fantastical laptop, especially for the price. But be aware, that some models (mine as well) have coil whine issue (1), so it may not be completely silent. Also, BIOS is very limited, you can disable security boot, choose boot device and that's pretty much it. However, Linux runs perfectly without jumping through any hoops.

(1) https://techtablets.com/forum/topic/xiaomi-air-12-5-inch-mod...

Thanks for those comments about the Xiaomi 12.

What do you find lacking in the BIOS? Don't you use EFI instead?

Yes, by BIOS I mean the hardware setup utility you invoke before booting OS. It is very barebones compared to what ASUS offers in their laptops. There are no advanced settings such as configuring CPU features, timings, etc. It doesn't really bother me, since I don't tend to tinker with those settings. But I dislike the trend of locking down hardware.

I have everything working on my Lenovo T480 with Fedora Linux.

It sounds like this isn't just some arbitrary decision, but Windows actually requires S3 to be removed in order to use the new suspend mode. From the thread: "When ACPI table was changed to support S3, Windows Modern Standby doesn't work. Modern Standby and Suspend/Resume functions are working exclusively."

Because someone was too lazy to bother with a if/else, because first implementations of S0 were so bad.

Make it a BOIS setting then.

No need: the bios can present different acpi tables depending on the OS who is asking for them. all it takes is a switch (case when..statement.

So there was no reason whatsoever to remove the code.

Because so many BIOSes provide completely broken ACPI tables to non-Windows OSes, I think Linux reports itself as being Windows to the ACPI code these days. So no, it probably can't.

I don't think this is even S0 suspend. At least a few year ago thinkpads have already moved to something called IRST, Intel's "suspend to SSD after sleeping for several hours" at firmware level. See https://mjg59.dreamwidth.org/26022.html for details. I actually got it working with the latest kernel at that time but didn't feel comfortable using it because of all the horror stories with firmware level shenanigans.

this is something else. IRST was Intel custom implementation, back when S0 did not exist. It required a custom partition.

IIRC, suspend to disk when battery runs out is now one of the standard S0 features.

At the OS level (windows 10) there is a telemetry to check the depletion rate, and initiate suspend to disk when the rate is too high or battery is too low.

Check the logs made by microsoft powercfg, they are very informative and will help you reach power savings close to what S3 allowed.

But I need that to work in Linux too, and last time I checked it wasn't as good.

> At the OS level (windows 10) there is a telemetry

Nitpick: "Telemetry" means "measurement far away". Does this get sent to microsoft ("tele") or is it just a measurement ("metric")?

Is that what is happening with the XPS line? My XPS 13 9333 goes to "sleep" but the backlight and the fan stay on, and the only way to revive it is to do a hard reset. And that's on latest windows 10.

Yes. You must either cook and inject your own ACPI table (taking inspiration from a similar model to save you time), or go with S0 only using a kernel patch.

I have done some bios and acpi code before on coreboot. It is tough, lots of work and no guaranteed results if you don't have access to the specs (NDA)

Anyway I really don't recommend you do that unless you have experience, documentation and time.

Maybe pedantic but according to https://docs.microsoft.com/en-us/windows/desktop/power/syste... S0 is the working state. Active suspend could be what they call Modern Standby or S0 low power.

Reply on news.ycombinator.com