Battery Detection Issue / ACPI

rc nai · 05-01-2011, 10:07 PM

My linux laptop isn't able to detect the current battery state. I am using slackware64 13.37 xfce with a Toshiba L645 laptop.

This is what I came up with so far.

Code:

lsmod

Module                  Size  Used by
snd_seq_dummy           1479  0 
snd_seq_oss            30116  0 
snd_seq_midi_event      5708  1 snd_seq_oss
snd_seq                52486  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          5473  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            40089  0 
snd_mixer_oss          17282  2 snd_pcm_oss
ipv6                  275315  24 
cpufreq_ondemand        9164  4 
acpi_cpufreq            6079  1 
freq_table              2435  2 cpufreq_ondemand,acpi_cpufreq
mperf                   1195  1 acpi_cpufreq
lp                      9781  0 
ppdev                   6021  0 
parport_pc             21214  0 
parport                30087  3 lp,ppdev,parport_pc
fuse                   66651  1 
i915                  400238  7 
drm_kms_helper         27035  1 i915
drm                   177345  3 i915,drm_kms_helper
i2c_algo_bit            5055  1 i915
processor              25982  1 acpi_cpufreq
video                  11949  1 i915
thermal_sys            13862  2 processor,video
joydev                 10279  0 
atl1c                  32572  0 
hid_a4tech              2292  0 
uvcvideo               62696  0 
videodev               65968  1 uvcvideo
button                  5013  1 i915
v4l1_compat            15658  2 uvcvideo,videodev
v4l2_compat_ioctl32    11199  1 videodev
rtc_cmos                9374  0 
rtc_core               14471  1 rtc_cmos
rtc_lib                 1978  1 rtc_core
usbhid                 36859  0 
battery                10535  0 
ac                      3249  0 
sparse_keymap           2984  0 
snd_hda_codec_hdmi     22985  1 
hwmon                   1473  1 thermal_sys
hid                    77723  2 hid_a4tech,usbhid
evdev                   9813  15 
output                  2020  1 video
shpchp                 26821  0 
psmouse                47222  0 
serio_raw               4534  0 
i2c_i801                8230  0 
snd_hda_codec_conexant    42870  1 
wmi                     8349  0 
i2c_core               19769  6 i915,drm_kms_helper,drm,i2c_algo_bit,videodev,i2c_i801
intel_ips              11442  0 
intel_agp              10824  1 i915
intel_gtt              14862  3 i915,intel_agp
agpgart                28874  3 drm,intel_agp,intel_gtt
snd_hda_intel          21915  2 
sg                     26495  0 
rfkill                 16442  0 
snd_hda_codec          71748  3 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel
snd_hwdep               6254  1 snd_hda_codec
snd_pcm                73762  4 snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer              19671  2 snd_seq,snd_pcm
snd                    58334  14 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
soundcore               5681  2 snd
snd_page_alloc          7297  2 snd_hda_intel,snd_pcm

Code:

dmesg | grep battery

[    7.233889] ACPI: Battery Slot [BAT1] (battery absent)

Code:

cat /proc/acpi/battery/BAT1/alarm
present: no
cat /proc/acpi/battery/BAT1/info
present: no
cat /proc/acpi/battery/BAT1/state
present: no

I added "acpi_osi=Linux, acpi=on, acpi=force" in lilo but no luck.
I don't think this is a BIOS issue because windows detects the battery life just fine. It also reports the percentage too. But yes so far it doesn't work in slackware. I am not dual booting by the way. I searched on google and found plenty of people who got the same problem, some of them are running fedora core and ubuntu. And yes it all relates to Toshiba satellite notebooks. So far I haven't found a solution yet. The last thing I don't want to do is rebuild a kernel because I don't have time at the moment. Does anyone have ideas?

Also, this is a seperate issue but I think it's worth mentioning. In /proc/acpi/processor/CPU0/ it only contains a file called throttling. Shouldn't it also have "info, limit, power, and throttling" in that directory?

This is what I get with the cat command:

Code:

cat /proc/acpi/processor/CPU0/throttling

state count:             8
active state:            T0
state available: T0 to T7
states:
   *T0:                  100%
    T1:                  87%
    T2:                  75%
    T3:                  62%
    T4:                  50%
    T5:                  37%
    T6:                  25%
    T7:                  12%

I use a program called conky that reports my cpu frequency and most of the time it's always at 0.93GHz instead of 2.53GHz. Sometimes it jumps to 1.20GHz and 2.53GHz but falls back down to 0.93GHz. Is this normal?

willysr · 05-01-2011, 10:26 PM

it seems that you are still using huge kernel. Try running with generic kernel and load the battery module and re-checked it again

plpl303a · 05-01-2011, 10:32 PM

Quote:

Originally Posted by rc nai

I use a program called conky that reports my cpu frequency and most of the time it's always at 0.93GHz instead of 2.53GHz. Sometimes it jumps to 1.20GHz and 2.53GHz but falls back down to 0.93GHz. Is this normal?

Modern CPU's vary their clock speed according to workload. So when the system is mostly idle, the CPU throttles back to a lower clock speed to save battery life and reduce heat. When workload increases, the clock speed rises.

dive · 05-02-2011, 07:26 AM

Quote:

Originally Posted by rc nai

Code:

cat /proc/acpi/battery/BAT1/alarm
present: no
cat /proc/acpi/battery/BAT1/info
present: no
cat /proc/acpi/battery/BAT1/state
present: no

Tried BAT0?

rejekt · 05-02-2011, 10:04 AM

I also have this issue with a Toshiba L650 laptop running Ubuntu 11.04 64-bit version. Except now that I've tried following a few peoples recommendations from searching forums and Google I've felt that I've gotten closer, but not quite there...

Code:

$> cat /proc/acpi/battery/BAT1/state 
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            24 mA
remaining capacity:      3591 mAh
present voltage:         12532 mV

$> dmesg | grep battery
[    1.421954] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
[    1.421990] ACPI: Battery Slot [BAT1] (battery absent)

$> sudo lshw -C power 
  *-power UNCLAIMED       
       description: OEM_Define1
       product: OEM_Define5
       vendor: OEM_Define2
       physical id: 1
       version: OEM_Define6
       serial: OEM_Define3
       capacity: 75mWh
  *-battery
       description: Lithium Ion Battery
       product: CRB Battery 0
       vendor: -Virtual Battery 0-
       physical id: 2
       version: 10/12/2007
       serial: Battery 0
       slot: Fake

$> acpi -V
Battery 0: Full, 100%
Battery 0: design capacity 4500 mAh, last full capacity 3591 mAh = 79%
Adapter 0: on-line
Cooling 0: LCD 0 of 7
Cooling 1: Processor 0 of 10
Cooling 2: Processor 0 of 10
Cooling 3: Processor 0 of 10
Cooling 4: Processor 0 of 10

This is what I'm currently getting with some of the hardware detection stuff. The majority of the commands now see the battery and that it exists, where it previous did not. However they are not really sure in which slot that it actually exists in, some are showing slot 0, others slot 1. I want to think that this is the issue, but I'm not sure how to reconfigure this at all.

I'm next going to attempt to download Ubuntu 11.04 32-bit version and run the live cd portion and see if that is actually able to determine the correct position of the battery and show the battery monitor.

If anyone else has any ideas until then, I'd be very interested in trying to get this to work.

Thanks,
Brian

allend · 05-02-2011, 07:44 PM

Do you see an entry for your battery under /sys/class/power_supply/?
The /proc/acpi interface is being deprecated.

rejekt · 05-02-2011, 09:23 PM

Oh, that's good to hear.

Yes, I do have an entry for the battery in that locations.

Code:

ls /sys/class/power_supply/BAT1
alarm               current_now   model_name     status      uevent
charge_full         cycle_count   power          subsystem   voltage_min_design
charge_full_design  device        present        technology  voltage_now
charge_now          manufacturer  serial_number  type

Sorry if I'm hi-jacking this thread a little bit with an Ubuntu distribution and not Slackware. Though I think it's an issue with Toshiba laptops in general.

rc nai · 05-03-2011, 10:54 PM

Quote:

Originally Posted by willysr

it seems that you are still using huge kernel. Try running with generic kernel and load the battery module and re-checked it again

Yea I'm currently using huge kernel. I switched to generic and reloaded the module with modprobe battery but still no luck with the battery detection.

Quote:

Originally Posted by dive

Tried BAT0?

I don't have BAT0, only BAT1

Quote:

Originally Posted by plpl303a

Modern CPU's vary their clock speed according to workload. So when the system is mostly idle, the CPU throttles back to a lower clock speed to save battery life and reduce heat. When workload increases, the clock speed rises.

I was worried for a bit, thanks.

Quote:

Originally Posted by allend

Do you see an entry for your battery under /sys/class/power_supply/?
The /proc/acpi interface is being deprecated.

In /sys/class/power_supply I only see an entry called ACAD.

Code:

ls -l /sys/class/power_supply/ACAD

/sys/class/power_supply/ACAD -> ../../devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ACAD

With the battery intact, it doesn't detect the battery or the AC adapter, but when using the AC adapter with the battery disconnected, XFCE does detect the AC adapter (adapter present). But it still says "not present" under cat /proc/acpi/battery/*/* and the entry in /sys/class/power_supply/ACAD is still the same.

willysr · 05-04-2011, 12:27 AM

in my laptop, i don't have /proc/acpi/processors

i only have /proc/acpi/battery/ and /sys/class/power_supply and they are showing the correct information

allend · 05-04-2011, 12:55 AM

Apparently there is a new kernel parameter that may address this issue 'acpi=copy_dsdt'.

From http://kerneltrap.org/mailarchive/gi...010/5/20/34989

Quote:

Some BIOS on Toshiba machines corrupt the DSDT, so add a new boot option acpi=copy_dsdt to workaround it.

rejekt · 05-09-2011, 07:31 PM

I tried adding the acpi=copy_dsdt to my Grub boot configuration and it did not help with the display of the battery monitor.

I don't know enough about ACPI or other protocols that keep track of this type of data to make any configuration changes. Somehow though I think it really just needs to figure out a way to point to battery 0 and not battery 1.

allend · 05-10-2011, 08:01 AM

After googling this for a while, I see that this is a complaint in many distributions.
You may wish to contribute to this recently opened kernel bug report. https://bugzilla.kernel.org/show_bug.cgi?id=34532

rc nai · 05-29-2011, 05:16 PM

Thanks for the link allend, that helped me a lot. By the way, I added 'acpi=copy_dsdt' while on 2.6.37.* and got a kernel panic. That was another different story.

Anyway, I got the battery problem fixed now. I'm currently running a custom kernel 2.6.39 with a modified DSDT file. I had a lot of help from these guys, much credit to all of them:

http://www.lesswatts.org/projects/ac...ridingDSDT.php
http://alien.slackbook.org/dokuwiki/...kernelbuilding
https://bugzilla.kernel.org/show_bug.cgi?id=34532

This was taken from a guy named steve from the above bugzilla link who said:

Quote:

I changed my DSDT and compiled it into a custom kernel.

Originally ther was this line under the EC0 device:
OperationRegion (EMEM, SystemMemory, 0xFF808001, 0xFF)

I changed it to this:
OperationRegion (EMEM, EmbeddedControl, 0x00, 0xFF)

I did all the above and that fixed it. Oh and by the way, I had received an error during my first kernel compilation about:

Code:

drivers/acpi/osl.c:66:38: fatal error: DSDT.hex: No such file or directory
compilation terminated.
make[2]: *** [drivers/acpi/osl.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [dricers] Error 2

To get pass that I had to put DSDT.hex into /usr/src/linux/drivers/acpi directory and rerun make. Oh and the link from lesswatts.org (above) said after the fix it should mention something about Table [DSDT] in dmesg, but I see no mentioning of that in dmesg, anyway it still works.

allend · 05-30-2011, 09:42 AM

Thanks for the feedback. My congratulations to you. That was not a trivial exercise!

tix · 12-16-2011, 02:16 AM

If one is interested in learning how to use their ACPI statistics to turn off their laptop (i.e. low battery turns off computer), the following article may be an interesting read:

Goto (LOL!):
http://www.gen.horizon-host.com/linux.php

click on:
Configuring ACPI - Laptop Battery and Automatic Shutdown

Tix

"Blessed are the angry, for they shall inherit the national debt."
--