please attach the acpidump output of your laptop.

is this a regression? does this problem exist in any previous kernel, say 2.6.35?

No, it's not a regression. There are though some changes in behavior between kernel versions. For example while using 2.6.35 (one of the latest versions) the gnome-power-manager tool gives some time estimations but they are greatly miscalculated.

But speaking of kernel 2.6.37. Here I don't see any time estimations in gnome-power-manager but the acpi tool gave me the following lines:

While charging:
Battery 0: Charging, 98%, charging at zero rate - will never fully charge.
after disconnecting and connecting AC adapter again:
Battery 0: Charging, 99%, 00:00:01 until charged  (while there is still more than 10 minutes until charged).

While discharging:
Battery 0: Discharging, 99%, 02:01:52 remaining

While fully charged:
Battery 0: Full, 100%

As you can see acpi shows the estimated time while discharging but it is extremaly jumpy - it can change from 1 hour to 2,5 in matter of 1 second and I think this is what stops gnome-power-manager from displaying a correct value.

Created attachment 44022 [details]
Acpi tables

The DSDT fixedly returns 0xFFFFFFFF as  "present voltage". This causes the problem. This is the bios issue.

            Name (BATI, Package (0x0D)
            {
                0x00,
                0x2710,
                0x2710,
                0x00,
                0xFFFFFFFF,
                0x03E8,
                0x01,
                0x64,
                0x64,
                "",
                "",
                "LiOn",
                "Sony Corp."
            })

According to the ACPI spec, _BIF.design_voltage = 0xFFFFFFFF
means "unknown design voltage"

/proc/acpi/battery/*/info:

present:                 yes
design capacity:         57240 mWh
last full capacity:      56930 mWh
battery technology:      non-rechargeable
design voltage:          119940 mV
design capacity warning: 1000 mWh
design capacity low:     1 mWh
cycle count:		  0
capacity granularity 1:  100 mWh
capacity granularity 2:  100 mWh
model number:            
serial number:           
battery type:            LiOn
OEM info:                Sony Corp.

clearly 119940 mV is bogus -- but it also isn't 0xFFFFFFFF.

acpi_battery_print_info(struct seq_file *seq, int result)
        ...
        if (battery->design_voltage == ACPI_BATTERY_VALUE_UNKNOWN)
                seq_printf(seq, "design voltage:          unknown\n");
        else
                seq_printf(seq, "design voltage:          %d mV\n",
                           battery->design_voltage);


So we are not getting 0xFFFFFFFF for design_voltage,
we are getting something that we think is legal.

hi len:
>  design voltage:          119940 mV
>  clearly 119940 mV is bogus -- but it also isn't 0xFFFFFFFF.
Yeah. The value looks abnormal. 

I think the main problems is caused by 'present voltage'.

            Name (PKG0, Package (0x04)
            {
                0x02,
                0xFFFFFFFF,
                0xFFFFFFFF,
                0xFFFFFFFF
            })
            Method (_BST, 0, NotSerialized)
The present voltage is returned as 0xFFFFFFFF.

Tianyu,
what's the current status of this bug?

This bug is caused by Bios's DSDT.The _BST fixedly returns 0xFFFFFFFF as "present voltage".

Well this bug is still present as "present voltage" is still reported as unknown.

Tianyu, if this is a BIOS problem, please close it as it can not be fixed.
But before that, we'd better confirm that the problem exists in windows as well.