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

paraffin · 2011-09-14 19:58:34

#####################################################
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)

Radioactiveman · 2011-09-14 21:32:03

I use a custom DSDT table to modify the fancontrol of my laptop.
Solution [1] is working fine for me, could you share your custom_dsdt.dsl?

paraffin · 2011-09-14 21:38:43

Yeah sure;
http://pastebin.com/iwrtEHf3
Would you mind doing a test kernel compile with this to see if it works?

paraffin · 2011-09-14 21:43:24

Actually this is the ACTUAL one I last used while trying to compile
http://pastebin.com/i8bE6kjy
It's the same except for the first line of code after the comments section. If you think it might be to do with the *.aml / *.hex discrepancy, let me know and I'll try changing that when I have time later tonight and won't ask you to give it a try...

Thanks a lot

paraffin · 2011-09-15 03:31:02

Yeah, so this is how it fails for me;
http://pastebin.com/FckV9eci
when I used
http://pastebin.com/NVBz4Gim,
referenced in the .config as /usr/src/custom.aml

I can't find any information anywhere on this...

Radioactiveman · 2011-09-15 15:24:38

paraffin wrote:

Would you mind doing a test kernel compile with this to see if it works?

This was my intention.
Anyway, I don't know what's wrong at your side. It compiles just fine here.
If you use x86_64 I can give you the package(s).

paraffin · 2011-09-15 17:06:27

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:

eldragon · 2011-09-15 20:54:44

i have a battery with the same condition you are stating..

non-rechargeable.

but it does work anyways... so i dont think thats your issue.

$  acpitool -B
  Battery #1     : present
    Remaining capacity : 65018 mAh, 100.0%, 59:06:26
    Design capacity    : 4400 mAh
    Last full capacity : 65018 mAh
    Present rate       : 1100 mA
    Charging state     : discharging
    Battery type       : non-recharge 
    Model number       : 36 mAh
    Serial number      : H12Y

is this your issue?

paraffin · 2011-09-15 22:53:40

Aaaaand now I keep getting compiler errors when I try to compile in a custom DSDT again. Not sure what's changed...

@Eldragon:
The following is what is reported seconds after inserting the battery:

$ acpitool -B
  Battery #1     : present
    Remaining capacity : 0 mAh, -nan%
    Design capacity    : 0 mAh
    Last full capacity : 0 mAh, -1.00% of design capacity
    Capacity loss      : 101.%
    Present rate       : 0 mA
    Charging state     : charging
    Battery type       : non-recharge 
    Model number       : 100 mAh

And this is what it changes to within ~15 seconds

$ acpitool -B
  Battery #1     : present
    Remaining capacity : 0 mWh, 0.00%, 00:00:00
    Design capacity    : 48840 mWh
    Last full capacity : 51680 mWh
    Present rate       : 639640 mW
    Charging state     : discharging
    Battery type       : non-recharge 
    Model number       : 100 mWh

I know it's actually discharging because when I first got it worked fine for over an hour despite not having a read on the capacity and now it can only support me for a minute or two, tops. I haven't been able to recharge it since, even with the computer turned off and plugged in.

My friend suggested I put the custom.aml in the mkinitcpio.conf FILES section. I did, but I don't see how I'm supposed to tell it to use it as a DSDT...

biltong · 2011-09-15 22:57:26

I just compiled a kernel on Ubuntu 10.04 with a custom DSDT today following those same instructions and it worked for me. I put my .hex file in <src>/include and set the path in my config appropriately, and I see you aren't doing that. Try give that a shot?

eldragon · 2011-09-15 23:34:25

your operating system is not the one in charge of managing a battery's charge..

your battery might be broken.

Arch Linux

#1 2011-09-14 19:58:34

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

#2 2011-09-14 21:32:03

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

#3 2011-09-14 21:38:43

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

#4 2011-09-14 21:43:24

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

#5 2011-09-15 03:31:02

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

#6 2011-09-15 15:24:38

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

#7 2011-09-15 17:06:27

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

#8 2011-09-15 20:54:44

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

#9 2011-09-15 22:53:40

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

#10 2011-09-15 22:57:26

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

#11 2011-09-15 23:34:25

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

Board footer