I get the impression that, in hardware companies, software is often not taken very seriously, when it can cripple the user experience for trivial bugs. It's also annoying that it's "proprietary" rather than open source, when hundreds of models will be using the same chipset in the same way. It's not a competitive advantage, the sleep code, it can only be a disadvantage if it's done badly.
Far too often, we have OEMs trying to build unique differentiating features without actually building much in the way of custom hardware, so you end up with some random thing hanging off GPIO pins or something like that, completely undocumented and driven by software that didn't really make it past proof of concept phase.
I had a desktop motherboard once that included a SATA power output intended to allow the software gimmick to fully power down hard drives you didn't need running. It was never worth the hassle.
I once used an HP laptop where the webcam disable switch was a USB HID device, and everything that connected that switch to the webcam functionality was implemented in software.
And then there are all the power management/tuning hacks written by people who've never even heard of control theory. Every "gaming" laptop ships with its own iteration on that disaster.
We are somewhere between market for lemons and a race to the bottom. It's both difficult to even a tech-savvy person to know if some problem is caused by acpi, and also if some acpi implementation is actually high quality.
One of the reasons why my next laptop will probably be a Framework. I got lucky with my current one which has worked flawlessly so far, but who knows if I would be lucky with the next one I buy?
A) Yet another example of why state machines need support directly in programming languages.
B) Look at salary for software engineer in semiconductor company then look at salary for software engineer at FAANG. Then ask where all the decent programmers are going to go.
This. I really wish I could be workikg in hardware, but the salary incentive is just there. Now I am stuck doing backend job to afford life and my low level and hardware hobby (reverse engineering games and firmwares, emulator, fpga stuffs), things that are magnitudes harder than making an api that put stuffs in DB and kafka
Wow that takes me back - I went through that maybe 15 years ago to fix something about my laptop at the time.
Fortunately haven't needed to since - I assumed that either laptop manufacturers got better at doing this stuff right, or (maybe more likely) Linux got better at interpreting their bugs.
I was trying to help a friend recently with a bizarre issue with a Dell laptop: the 2 key (and only the 2 key) is unreliable. Normally I'd say "hardware problem" but it acted more like a software bug. Among other signs, it's unreliable in Windows and the BIOS but not in Linux.
Unfortunately, I don't have the skills to even diagnose the problem, let alone fix it. And my friend isn't willing to put Linux on it since he wants to sell it.
I remember needing a patch to the DSDT on a Dell latitude x300 for linux to work proberly (~20 years ago?). It was attached to the initrd. IIRC one problem was that the microsoft ACPI table compiler produced code that was illegal under some interpretation of the standard, and the intel tools on linux didn't like that.
Seems par for the course with Dell lately.
My XPS has a Wifi+ACPI firmware bug, wherein when the wifi says, hey can i go into power save mode, and the ACPI grabs its ankles, kernel panic!
For years I thought It was a linux thing but after stumbling on the motherload of complaints im saddened. Its been my first linux laptop and its sad to see that the shortcommings had nothing to do with distro, rather hardware regression. Theres no plans to fix either. Luckly it happens maybe twice a year.
It’s pretty much the same on windows. It’s not an ideal workaround but I recently turned of C-states in the BIOS and since I’m always plugged in anyway, it seems to have stabilized a bit.
It seems to be connected with the WIFI card and the machine going to sleep. People have had their entire motherboards replaced and it hasn’t solved the problem. It’s annoying because I spent a lot of money on my XPS and it’s basically junk.
My experience is that even Apple has its issues. The most reliable laptop I've had is my current Lenovo and
Sleep works flawlessly in either Windows or Debian. Even my work HP is fine, Windows does sleep/wake flawlessly every time without fail.
I don't know, I had my M1 Air reboot once because I had the wild idea to close the lid while it was charging. Usually only one of the two is happening. But a friend that has been around MacBooks for longer told me they do it. Hence my comment.
I do wonder ... I run ubuntu ocular t2 on a macpro '16... everytime I accidentally close the lid the laptop becomes unresponsive. I have to cycle power which usually then needs a manual fsck before it can boot normally.
I had tons of wierd boot/reboot issues with my old dell precision m4800. It stuck before boot and required voodoo rituals to finally boot successfully into linux or windows. Now it wasn’t used for some years and having installed recently a modern linux it works just fine now, like never before. As if the computer finally fixed itself.
More likely your updated Linux kernel checks for those specific bugs in those specific ACPI tables. If it finds them, it tells the kernel to ignore them and replace them with driver code. And then they actually bothered to test the driver code and make sure that it actually works.
See recently: https://github.com/Zephkek/Asus-ROG-Aml-Deep-Dive
I get the impression that, in hardware companies, software is often not taken very seriously, when it can cripple the user experience for trivial bugs. It's also annoying that it's "proprietary" rather than open source, when hundreds of models will be using the same chipset in the same way. It's not a competitive advantage, the sleep code, it can only be a disadvantage if it's done badly.
1. Design hardware.
2. Build hardware.
3. Oh, no! The hardware has a bug! We'll somehow fix it in software.
And fixes come only if there is an economic reason for doing so. As soon as the company starts developing the next product line, you're on your own.
I wish that was how it worked.
Far too often, we have OEMs trying to build unique differentiating features without actually building much in the way of custom hardware, so you end up with some random thing hanging off GPIO pins or something like that, completely undocumented and driven by software that didn't really make it past proof of concept phase.
I had a desktop motherboard once that included a SATA power output intended to allow the software gimmick to fully power down hard drives you didn't need running. It was never worth the hassle.
I once used an HP laptop where the webcam disable switch was a USB HID device, and everything that connected that switch to the webcam functionality was implemented in software.
And then there are all the power management/tuning hacks written by people who've never even heard of control theory. Every "gaming" laptop ships with its own iteration on that disaster.
Well, if your competitors do it badly and you do it well, it could be a competitive advantage…
We are somewhere between market for lemons and a race to the bottom. It's both difficult to even a tech-savvy person to know if some problem is caused by acpi, and also if some acpi implementation is actually high quality.
One of the reasons why my next laptop will probably be a Framework. I got lucky with my current one which has worked flawlessly so far, but who knows if I would be lucky with the next one I buy?
and the HN discussion about it here: https://news.ycombinator.com/item?id=45271484
A) Yet another example of why state machines need support directly in programming languages.
B) Look at salary for software engineer in semiconductor company then look at salary for software engineer at FAANG. Then ask where all the decent programmers are going to go.
B)
This. I really wish I could be workikg in hardware, but the salary incentive is just there. Now I am stuck doing backend job to afford life and my low level and hardware hobby (reverse engineering games and firmwares, emulator, fpga stuffs), things that are magnitudes harder than making an api that put stuffs in DB and kafka
The process for shipping a kernel workaround seems to be documented here, for those motivated to patch these ACPI bugs:
https://forums.gentoo.org/viewtopic-t-122145.html
Wow that takes me back - I went through that maybe 15 years ago to fix something about my laptop at the time. Fortunately haven't needed to since - I assumed that either laptop manufacturers got better at doing this stuff right, or (maybe more likely) Linux got better at interpreting their bugs.
I was trying to help a friend recently with a bizarre issue with a Dell laptop: the 2 key (and only the 2 key) is unreliable. Normally I'd say "hardware problem" but it acted more like a software bug. Among other signs, it's unreliable in Windows and the BIOS but not in Linux.
Unfortunately, I don't have the skills to even diagnose the problem, let alone fix it. And my friend isn't willing to put Linux on it since he wants to sell it.
I remember needing a patch to the DSDT on a Dell latitude x300 for linux to work proberly (~20 years ago?). It was attached to the initrd. IIRC one problem was that the microsoft ACPI table compiler produced code that was illegal under some interpretation of the standard, and the intel tools on linux didn't like that.
Seems par for the course with Dell lately. My XPS has a Wifi+ACPI firmware bug, wherein when the wifi says, hey can i go into power save mode, and the ACPI grabs its ankles, kernel panic! For years I thought It was a linux thing but after stumbling on the motherload of complaints im saddened. Its been my first linux laptop and its sad to see that the shortcommings had nothing to do with distro, rather hardware regression. Theres no plans to fix either. Luckly it happens maybe twice a year.
https://www.dell.com/community/en/conversations/xps/xps-15-9... https://www.dell.com/community/en/conversations/xps/xps-15-9...
It’s pretty much the same on windows. It’s not an ideal workaround but I recently turned of C-states in the BIOS and since I’m always plugged in anyway, it seems to have stabilized a bit.
It seems to be connected with the WIFI card and the machine going to sleep. People have had their entire motherboards replaced and it hasn’t solved the problem. It’s annoying because I spent a lot of money on my XPS and it’s basically junk.
Someone share this with Apple, they have the same bug.
In my experience Apple devices are the only ones that get sleep right.
My experience is that even Apple has its issues. The most reliable laptop I've had is my current Lenovo and Sleep works flawlessly in either Windows or Debian. Even my work HP is fine, Windows does sleep/wake flawlessly every time without fail.
I don't know, I had my M1 Air reboot once because I had the wild idea to close the lid while it was charging. Usually only one of the two is happening. But a friend that has been around MacBooks for longer told me they do it. Hence my comment.
Never seen this in my life across five MacBooks. Was this around 2am and you’d previously asked it to do an update “tonight”?
I do wonder ... I run ubuntu ocular t2 on a macpro '16... everytime I accidentally close the lid the laptop becomes unresponsive. I have to cycle power which usually then needs a manual fsck before it can boot normally.
I had tons of wierd boot/reboot issues with my old dell precision m4800. It stuck before boot and required voodoo rituals to finally boot successfully into linux or windows. Now it wasn’t used for some years and having installed recently a modern linux it works just fine now, like never before. As if the computer finally fixed itself.
More likely your updated Linux kernel checks for those specific bugs in those specific ACPI tables. If it finds them, it tells the kernel to ignore them and replace them with driver code. And then they actually bothered to test the driver code and make sure that it actually works.
Maybe newer kernels patch the DSDT, like discussed in the comments of the blog post.
Friends don't let friends run software build by hardware folks.
Move one instruction from above to below the IF?
Toshiba Satellite had an infuriating ACPI bug that prevented Linux from reading the battery percentage!