[SOLVED]Custom DSDT not loading - OEM battery doesn't work - Sony Vaio

Question

EDITING ORIGINAL POST TO POST SOLUTION so I don't do a massive bump
Installed windows and ran the BIOS flasher that came with the battery. Didn't work until I changed a line in the plaintext configuration file (config.ini or something) it comes with. Changed "Capacity: 20" to "Capacity: -10". This changed the battery charge requirement from 20% to negative ten percent (any negative number will do), allowing the program to run and flash the BIOS. Didn't realize I could do that, but it fixed  the problem 100%.
#### BEGIN ORIGINAL POST: ################################
Hey guys,
I'm a bit of a linux noob, but I've spent many hours this week trying to fix this issue on my own and have learned a lot about making custom kernels, hardware stuff, ACPI, and ABS. However, nothing I've done has worked and I've hit a wall. For reference, I'm on a Sony Vaio VGN-FZ4000 with linux-3.0 base kernel, gnome3/gdm. The battery is made in china and doesn't list a manufacturer, just model number BPS8, 52000mAh.
[Backstory]
So I recently got an OEM battery to replace the broken original, which hasn't worked since before I installed arch (though it worked with an Arch install I did a couple years ago). When I first plugged it in, the gnome battery symbol popped up listing the battery at 0% with an exclamation icon. I unplugged from AC power and the laptop still ran, but the battery monitor just said it was at 0% and 'Estimating' remaining time. I figured this was a glitch with gnome or just because it was this battery's first cycle so I let it run down until it hard-crashed. Then I plugged back into AC and tried to turn on the computer, but it wouldn't do anything until I removed the battery.
Looking into the problem I discovered this was due to the ACPI firmware table DSDT being compiled for Windows, which has, shall we say, fewer restrictions on sanity than the Intel ASL compiler used for UNIX systems. Sure enough I extracted /sys/firmware/acpi/tables/DSDT to find that its section about the battery contained the entry 'Zero' for Battery Technology, which translates to "non-rechargeable", rather than 'One', which makes it chargeable. acpitool confirmed this; my system thought the battery was non-rechargeable and was constantly discharging it. Needless to say I've only been putting it in temporarily to test solutions since.
[/backstory]
[tl;dr] DSDT firmware contains malformed battery description, now I can't get my system to run with a custom DSDT. [/tl;dr]
Attempted solutions:
[1]
Extract, modify, recompile DSDT and include it with the kernel compilation .config options
CONIFG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/custom_dsdt.hex
CONIFG_STANDALONE=n
as suggested here, a page linked to by the arch wiki page on DSDT.
I followed the instructions but no matter what this has generated errors during the kernel compilation, sometimes due to every line containing unexpected \231 (or other numbers) characters, sometimes finding some error in the DSDT file and then claiming that the driver it was compiling (ol.c somewhere in the drivers/acpi section I believe) had references to undefined functions all over the place. I CANNOT compile with a custom DSDT specified.
[2]
Place recompiled DSDT in /lib/initcpio/custom.dsdt and add 'dsdt' to the HOOKS in mkinitcpio (and rebuild the initramfs-linux-*.img, of course). Another version of this included recompiling the kernel with CONFIG_STANDALONE disabled.
In neither of these situations has the running DSDT ever been anything but the BIOS-supplied one and not once has the battery shown any different behavior.
acpitool and $ cat /proc/acpi/battery/BAT0/info have consistently claimed the information specified in the BIOS-supplied DSDT; the battery is non-rechargeable and is discharging at an unknown rate. Sometimes acpi will even report that the battery has zero capacity.
The arch wiki does say mkinitcpio doesn't support the dsdt hook as of 2.6.30, but [1] didn't work either and mkinitcpio -H dsdt still told me to try this so I did.
[3]
The final solution I have tried has been to do [2] but to recompile the kernel with the legacy support for battery and ac adapter stuff disabled. I tried this because it was suggested in the kernel.log;
Sep  13 11:51:03 localhost kernel: [   11.740059] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Sep  13 11:51:03 localhost kernel: [   11.753434] ACPI: AC Adapter [ADP1] (on-line)
The corresponding line now reads
ACPI: AC Adapter [ADP1] (on-line)
(The same goes for the battery BAT0)
but all this does is remove the battery/ and adp1/ folders from /proc/acpi/ and break acpitool functionality. The log still doesn't mention the dsdt hook, either.
[4]
The old way to do this was to use the acpi-dsdt-initrd-patch-* patch, but that hasn't been updated for modern kernels, presumably because of the new "functionality" from mkiniticpio. The current kernel .config doesn't include any options for ACPI initrd/initramfs support or reading a DSDT from initramfs, which is the functionality provided by this patch.
This covers all the methods I've been able to find on the internet and I'm at a loss for what to do. Am I doing something wrong in [1]? Under what conditions will the compiler fail/succeed with a CONFIG_ACPI_CUSTOM_DSDT_FILE?
When I recompile I fix the 'Zero' definition and a couple compiler errors and warnings. The errors come from section length definitions, which read as 0x00000000 rather than the appropriate max-min value so I fix those, and the warnings come from _T_* methods belonging to the compiler, so I refactor the code to remove the initial underscores. The last warning comes from an isolated And statement that's within brackets (compiler complains it doesn't do anything), but if I remove that the compiler fails hard.
Thanks to anyone who's read this far.  Please let me know if you have any ideas how to get my system to use a customized DSDT.
Last edited by paraffin (2011-09-29 23:20:30)

Answer 1

Thanks for the offer, Radioactive man However, I'm actually compiling a customized kernel with the linux-ck and -sony patches, so your packages won't help. (The custom kernel works fine and I've tested this battery behavior on the the regular, -ck, and -sony kernels as well)
Anyway, so I tried another compile with
CONFIG_PREVENT_FIRMWARE_BUILD=n in addition to the options listed in [1] and that time it compiled.
Unfortunately it still didn't load the DSDT!
I did catch a quick little error message that turned up in kernel.log though;
/var/log/kernel.log:Sep 15 11:50:24 localhost kernel: [    0.925780] acerhdf: unknown (unsupported) BIOS version Sony Corporation/VGN-FZ4000E/R2110J7, please report, aborting!
acerhdf is a fan controller module for the Aspire One, and perhaps I left that in the kernel config and it's preventing the custom DSDT from loading, even though the acerhdf module never gets loaded itself, nor is it in my rc.conf or anything else... If that was the cause of all this, I'm gonna be angry...
Anyway, this message does not appear with my latest kernel build because I took off the custom DSDT option, hoping to be able to use ACPI_CUSTOM_METHOD=y, which supposedly allows one to inject a custom AML method into a debug fs. It wouldn't have worked anyway, as it doesn't let you modify Device sections, but even with a dummy method insertion it didn't give my root modification privileges as it was supposed to...
Will try recompiling AGAIN with this CONFIG_ACERHDF=n (it's simply 'not set' in my current .config), while also enabling the custom kernel etc. If this doesn't work I have no idea what I'll do.
Anyway, thanks for your help and time: