Not Fixing The Possibly Unfixable
March 23rd, 2023
Last updated
March 23rd, 2023
Last updated
Around December 2022, one of my friends gave me an old laptop he didn't want. He didn't know if it still worked or not, but I decided to take it off his hands because I was curious of what it was capable of. The laptop in question was an Acer Aspire One 532h. This laptop was marketed as a "netbook", which Wikipedia defines as "a small and inexpensive laptop designed primarily as a means of accessing the Internet". Netbooks aren't made anymore, at least not marketed as such. The only modern laptop that could qualify as a netbook are Chromebooks. So what can this netbook do?
Wow! That's horrible, at least for standards nowadays. The sticker on the laptop detailing the specs is laughable. The sticker also says WiFi Certified, but it doesn't say to what standard. That standard is 802.11n (also known as WiFi 4, created in 2008). 802.11n only gets a max throughput of 600 Mbps. Newer standards like 802.11ax (WiFi 6, 2019) get max throughput speeds of 9.6 Gbps (theoretically). We also get a 10.1" display, which gives you a max resolution of 1024x600. That's an aspect ratio of 128:75. When was this laptop released again? I couldn't find an exact date, but the early models using Intel Atoms were released around 2008.
Let's ignore the specs for now. I bought a charger for the laptop on Amazon for $10 and powered it on. As evident of the stickers on the laptop, this thing was still running Windows 7 Starter. It's not really a good thing to be running an OS as old as Windows 7, so I searched online for some lightweight operating systems, considering that any modern Windows installation wouldn't be able to make it past installation. A promising candidate was Lubuntu, a flavor of Ubuntu using LXQt for the DE instead of GNOME. Lubuntu was designed to be lightweight, so I decided to go with it.
Unfortunately, Lubuntu wasn't really a good choice. While Lubuntu may be lightweight, it wasn't lightweight enough. There were many frequent freezes, where the laptop would just lock up with the only escape being a hard shutdown. I left the laptop to collect dust after enough experimenting.
A few months later, I revisited the laptop with a new idea. I was going to install an OS, but skip the DE. I could just use TUI applications. Genius! Not. TUI sucks. I ended up going with Debian and Xfce for the DE.
Success, kinda. The laptop runs fine enough, and it doesn't freeze up like Lubuntu. That's fine and all, but this laptop is a netbook. Can it browse the Internet? Yes, but there is a caveat. Any "heavy" website, meaning a website with a lot of things going on, will take a while to load. Unfortunately, most websites are heavy. But simple websites load pretty fast.
So that's pretty much it. An old laptop that performs poorly. Case closed. Or is it?
An interesting thing I noticed with both OS installations was an error that appears when the laptop is booted up.
You would think this would be an error you would see fly by in the terminal while the laptop was booting up, but this would actually cause Lubuntu to hang for about 20 seconds, and Debian 5 seconds. So what is this error?
Automatic Configuration and Power Interface (ACPI) is an interface created in 1996 used for providing power management controls to the operating system. While ACPI is old, it is still widely used to this day and is still receiving updates. ACPI supersedes Advanced Power Management (APM), which was only available to the BIOS.
OSPM stands for Operating System Power Management, and according to Technopedia, "OSPM is an operating system technology for managing the power of the underlying platform and switching it between different power states. OSPM is primarily designed to work on handheld or portable devices such as laptops and tablets".
However, the problem isn't with OSPM, it's with _OSC. According to the documentation. _OSC takes 4 arguments: UUID, Revision ID, Count, and Capabilities Buffer. Fortunately, none of this information is important to know. What's important to know is that there are 4 arguments expected. So according to the error, this function was declared to take 5 arguments when it actually is expecting 4.
However, the ACPI specification listed is from 2014, while this laptop is from 2008. So did the ACPI specifications originally have 5 arguments instead of 4? I checked the ACPI 3.0 specification from 2006, and the _OSC function still only has 4 arguments, so this was most likely a bug.
Is this fixable? Possibly. The aforementioned FreeBSD user was able to fix it, and even included a tutorial on his post for fixing it. I started following this guide, until I realized I was using Debian, and not FreeBSD.
After decompiling this file, we can find the line:
Yep, this is the source of the issue. Whoever wrote this screwed up. Following the previously mentioned tutorial, this code can be fixed, recompiled, and used in place of the original code. Unfortunately, the FreeBSD tutorial ends here. If I want to use this edited DSDT file, I'm going to have to recompile my kernel. Damn.
So after recompiling with iasl -tc DSDT.dsl, we get this:
Well that's great, this won't even compile. What was this compiled with originally? Using dmesg | grep DSDT gets this:
So this was compiled with... 1025? Whatever that is, it seems Intel's compiler is not going to handle this correctly. So what now?
This error can be entirely avoided by using a higher log level. Note the word avoided, not fixed. This is achieved by using the parameter loglevel=3 in the GRUB config inside GRUB_CMDLINE_LINUX_DEFAULT. Is this a good solution? No, but should I have to pick up the slack of some programmers from Acer in 2008? Also no.
So the error is coming from ACPI, and according to the error, it's coming from a function called _OSC. What does _OSC do? A user on the FreeBSD forums , and according to the , the function _OSC stands for "Operating System Capabilities", and is used "to convey OSPM capabilities to the platform".
So to loosely follow this tutorial, I needed to install acpidump. This command is included with acpica-tools, which can be installed with apt. ACPI Component Architecture (ACPICA) has some useful tools with handling all things ACPI related. The first part includes the command acpidump -dt > DSDT.asl. While acpica-tools includes the command acpidump, the options -dt are not included. It seems these options are only included in FreeBSD, which was my first problem. Fortunately, the solution to this was the command cat /sys/firmware/acpi/tables/DSDT > DSDT.dat from from 2014. This DSDT table needs to be decompiled which is done with iasl -d DSDT.dat, which generates a file called DSDT.dsl. iasl is Intel's ASL compiler and disassembler, ASL standing for ACPI Source Language.