Created attachment 158791 [details]
dmesg

Created attachment 158801 [details]
lspci

(In reply to benjamin from comment #0)
> Created attachment 158781 [details]
> acpidump
> 
> Hithere,
> 
> i've got a new Schenker S403 (Clevo W740SU) with Debian jessie running on it.
> Battery information and things like that on Windows works fine.
> 
> If i try to read the battery status per "acpi -bi" i get a "Battery 0:
> Discharging, 35%, rate information unavailable" back.
> 
> A cat on current_now gives me a wired error message:
> root@nb:~# cat /sys/class/power_supply/BAT0/current_now 
> cat: /sys/class/power_supply/BAT0/current_now: No such device

Is it always the case or just sometimes?

The 'no such device' error means the battery is not present according to the _STA control method return value. The interesting thing is that the battery status information returned from _STA is got from a field in memory space:

        Device (BAT0)
        {
            Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)  // _HID: Hardware ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (^^PCI0.LPCB.EC.ECOK)
                {
                    If (^^PCI0.LPCB.EC.BAT0)
                    {
                        Return (0x1F)
                    }
                    Else
                    {
                        Return (0x0F)
                    }
                }
                Else
                {
                    Return (0x0F)
                }
            }
        }

I had though the BAT0 is a field in EC address space, but it's defined as:

        Device (EC)
        {
            Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  // _HID: Hardware ID
            Name (_GPE, 0x17)  // _GPE: General Purpose Events
            Name (ECOK, Zero)
            ... ...
            OperationRegion (RAM, SystemMemory, 0xFF700100, 0x0100)
            Field (RAM, ByteAcc, Lock, Preserve)
            {
                ... ...
                Offset (0x10),
                ADP,    1,
                AFLT,   1,
                BAT0,   1,
                BAT1,   1,
            }
        }

so it is a memory bit that decides if the battery is present or not.

And that memory space is marked as reserve by the BIOS table:
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved

I wonder do you have any special driver installed under Windows? i.e. any vendor specific driver?

I have the same model laptop and have the same problem. I have noticed various instances of people having the same problem scattered around the internet, however, nobody seems to have an answer. This bug report seems to be the most complete and most explored given Aaron Lu's comment above.

If I may answer their question, there is no vendor specific driver required to access battery information or discharge rate under Windows 8.1. Also, Linux is able to tell that the battery is present as the files in /sys/class/power_supply/BAT0/ are populated with accurate information (except for the current_now file which is the problem).

I have read that the most likely way to fix issues involving ACPI will be to dissassemble, fix, and recompile the DSDT. I started an attempt at this process, but couldn't figure out what code to fix or how to fix it.

The bug is marked as status:NEEDINFO, what further information is required?

Created attachment 172761 [details]
Add some debug statements to battery module

Please apply this debug patch and then cat /sys/class/power_supply/BAT0/current_now, then attach dmesg.

The error of reading current_now may be due to the "Battery remaining capacity" information provided by the _BST control method is not valid, where the BRC0 is used to provide such info but it is also a fieled in the memory region so I really don't see why that value can provide such a value, unless some other software components are filling that value somehow. Generally, the information should be provided by a field in the EmbeddedControl operation region, instead of a SystemMemory operation region.

(In reply to Apokalypzx from comment #5)
> If I may answer their question, there is no vendor specific driver required
> to access battery information or discharge rate under Windows 8.1. Also,

Is it the pre-installed Win8? Is there some vendor specific software installed?

> Linux is able to tell that the battery is present as the files in
> /sys/class/power_supply/BAT0/ are populated with accurate information
> (except for the current_now file which is the problem).

Yes, the present information is provided by the _BIF or _BIX while the things like (dis)charging rate information is provided by the _BST. And the _BST doesn't look correct to me.

> The bug is marked as status:NEEDINFO, what further information is required?

No, just forgot to change the status, sorry about that.

Created attachment 172911 [details]
dmesg-bat-debug.log

Here is my dmesg after accessing /sys/class/power_supply/BAT0/current_now
after patching the module.
(Hopefully the attachment shows up, I'm adding the attachment and replying
via email.)


(In reply to Aaron Lu from comment #7)

> Is it the pre-installed Win8? Is there some vendor specific software
installed?

I had installed Win8.1 from disk directly from Microsoft. No oem disks and
no vender specific software at all.

Thank you for your attention in this.

On Mon, Mar 30, 2015 at 11:59 PM, <bugzilla-daemon@bugzilla.kernel.org>
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=88891
>
> --- Comment #6 from Aaron Lu <aaron.lu@intel.com> ---
> Created attachment 172761 [details]
>   --> https://bugzilla.kernel.org/attachment.cgi?id=172761&action=edit
> Add some debug statements to battery module
>
> Please apply this debug patch and then cat
> /sys/class/power_supply/BAT0/current_now, then attach dmesg.
>
> The error of reading current_now may be due to the "Battery remaining
> capacity"
> information provided by the _BST control method is not valid, where the
> BRC0 is
> used to provide such info but it is also a fieled in the memory region so I
> really don't see why that value can provide such a value, unless some other
> software components are filling that value somehow. Generally, the
> information
> should be provided by a field in the EmbeddedControl operation region,
> instead
> of a SystemMemory operation region.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Created attachment 172921 [details]
dmesg-bat-debug-new.log

My dmesg attachment for my last reply (comment #8) was accidentally taken
while on AC power.
I unplugged the power and checked /sys/class/power_supply/BAT0/current_now
again.
The new dmesg is in the attachment.

Thanks for the log.

The "no such device" error is indeed confusing, it actually means the current_now information(the current being supplied or accepted through the battery) is not available, i.e. the firmware doesn't return such information to us. The remaining capacity is provided correctly though.

I guess Windows doesn't provide such information either, only remaining capacity. I think the estimated remaining time is calculated by: remaining_capacity / current_now, and since current_now is not available, Windows may not be able to give you such information. But Windows may use other ways to do the estimation, so hard to say here.

Can someone please confirm if Windows is capable of providing the discharge rate information? And if so, is it accurate?

(In reply to Aaron Lu from comment #11)
> Can someone please confirm if Windows is capable of providing the discharge
> rate information? And if so, is it accurate?

Hello,
I’ve use windows 7 for around 2 years on my Clevo P150em, with a HDD bought separately from my laptop and downloaded windows directly from MSDNA (without vendor specific software).

Currently 4.0.4–2–ARCH is running on my laptop.
I’ve got this error too : cat: /sys/class/power_supply/BAT0/current_now: No such device

upower -i /org/freedesktop/UPower/devices/battery_BAT0 is capable to show my discharge rate (aka power consumption), but only when my AC is unplug.
I’m quite sure they’re simply doing some math. Something like :
POWER_SUPPLY(at

(In reply to Aaron Lu from comment #11)
> Can someone please confirm if Windows is capable of providing the discharge
> rate information? And if so, is it accurate?

Hello,
I’ve used windows 7 for around 2 years on my Clevo P150em, with a HDD bought separately from my laptop and downloaded windows directly from MSDNA (without vendor specific software).

Currently 4.0.4–2–ARCH is running on my laptop.
I’ve got this error too : cat: /sys/class/power_supply/BAT0/current_now: No such device

upower -i /org/freedesktop/UPower/devices/battery_BAT0 is capable to show my discharge rate (aka power consumption), but only when my AC is unpluged.
I’m quite sure they’re simply doing some math. Something like :
(CHARGE_NOW(at t(1))—CHARGE_NOW(at t(0))) / (t(1)—t(0))

I can see it with gnome-power-statistic too. However I’ve no clue how they get it.


A lot of talk for few relevant informations, right ? Well here is my point :

I don’t know how the measurements are done, neither how to find the method.
Even though I find the discharge rate on Windows, it wouldn’t mean it’s what you are looking for.
I’m not asking you to give me a private course but a starting point or some links would be highly appreciate.

Regards

Thanks for the info.

(In reply to Brice Saunier Debes from comment #13)
> Hello,
> I’ve used windows 7 for around 2 years on my Clevo P150em, with a HDD bought
> separately from my laptop and downloaded windows directly from MSDNA
> (without vendor specific software).
> 
> Currently 4.0.4–2–ARCH is running on my laptop.
> I’ve got this error too : cat: /sys/class/power_supply/BAT0/current_now: No
> such device
> 
> upower -i /org/freedesktop/UPower/devices/battery_BAT0 is capable to show my
> discharge rate (aka power consumption), but only when my AC is unpluged.
> I’m quite sure they’re simply doing some math. Something like :
> (CHARGE_NOW(at t(1))—CHARGE_NOW(at t(0))) / (t(1)—t(0))
> 
> I can see it with gnome-power-statistic too. However I’ve no clue how they
> get it.

That doesn't matter.
So I suppose no problem now?

the error:
cat: /sys/class/power_supply/BAT0/current_now: No such device
means the firmware is not providing information on the current being supplied or accepted through the battery’s terminals. But the user space is capable of estimating such information based on remaining_capacity as you have illustrated. If you are a app developer, all you need to know is that the firmware doesn't provide such information and you need to estimate it by other ways; if you are a normal user, no need to care about it as long as the tool like upower or some UI tools provided such information to you.