"Battery may be broken" message at start-up

mq15 · 10-04-2009, 02:50 AM

Hello friends
I have HP dv6000 with fedora 9 and Windows Visata installed. Today I loaded fedora after 20/30 days and I get a pop message in the system tray informing:

Quote:

Battery may be broken
Your baterry has a very low capacity (45%), which means that it may be old or broken.

Note that Windows Vista gives no complaint regarding battery. Please suggest what may be the problem.

Regards

business_kid · 10-04-2009, 03:57 AM

As a first step, I would suggest running lm_sensors to load all the relevant modules and installing acpitools. Then try

acpitool

mq15 · 10-04-2009, 11:44 AM

Dear I don't know about lm_sensors and running this. Neither I know how to install acpitools.
Please help me.

michaelk · 10-04-2009, 05:24 PM

Your problem is probably similar to the one in the posted URL and is a bug in hal. Updating to the latest Fedora 11 might fix the problem and is recommended anyway since version 9 is no longer supported.

https://bugzilla.redhat.com/show_bug.cgi?id=439460

syg00 · 10-04-2009, 05:54 PM

No I think this is just normal procedure for the mega distros. I recently had the same reported on both Fedora and Ubuntu. Vista does appear to recognise the same - in my case I got notification from the Dell tools; maybe the default HP settings don't.
My laptop is about 18 months old - battery simply degrading with age I guess. Certainly doesn't last as long mobile as it used to.

business_kid · 10-05-2009, 03:03 AM

Quote:

Originally Posted by mq15

Dear I don't know about lm_sensors and running this. Neither I know how to install acpitools.
Please help me.

If you want to survive with linux, you need to help yourself.
man lm_sensors. or just run sensors_detect
man acpitool

mq15 · 10-05-2009, 12:41 PM

thanks syg00 and bussiness_kid.

Quote:

[root@localhost ~]# man lm_sensors
No manual entry for lm_sensors
[root@localhost ~]# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
[root@localhost ~]# man sensors
Formatting page, please wait...
[root@localhost ~]# sensors-detect
# sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): y
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 0000:00:1f.3: Intel 82801H ICH8

We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported I2C/SMBus adapters, you can have
them scanned by manually loading the modules before running this script.

To continue, we need module `i2c-dev' to be loaded.
Do you want to load `i2c-dev' now? (YES/no): y
Module loaded successfully.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

Next adapter: SMBus I801 adapter at 1c00 (i2c-0)
Do you want to scan it? (YES/no/selectively): y
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): y
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM78-J' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): y
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... No

Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): y
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD K10 thermal sensors... No
Intel Core family thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `coretemp' (should be inserted):
Detects correctly:
* Chip `Intel Core family thermal sensor' (confidence: 9)

Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): y
Starting lm_sensors: loading module coretemp [ OK ]
[root@localhost ~]#

I little understand what all this happened.

business_kid · 10-06-2009, 04:05 AM

You have a battery problem. Battery level is a function of acpi.
sensors-detect hunted around in your box for the various sensors and other devices that provide feedback. It then arranged to load kernel modules for these on bootup. It's a way of making sure you don't have the wrong driver driving half of some chip. I think you will understand it doesn't hurt to have the correct drivers.

elliott678 · 10-06-2009, 06:36 AM

This command should give you all of the information about your battery:

Code:

cat /proc/acpi/battery/BAT0/info

Your battery might be detected as BAT1 or BAT2 for some reason, even if it is the only battery, it is odd, but I have seen it happen.

Here is an example of mine:

Code:

[elliott@901-arch ~]$ cat /proc/acpi/battery/BAT0/info 
present:                 yes
design capacity:         6580 mAh
last full capacity:      5679 mAh
battery technology:      rechargeable
design voltage:          8400 mV
design capacity warning: 226 mAh
design capacity low:     226 mAh
capacity granularity 1:  65 mAh
capacity granularity 2:  65 mAh
model number:            901
serial number:            
battery type:            LION
OEM info:                ASUS

It should be comparing the design capacity to the last full charge capacity to come up with the broken battery message. Mine has lost about 1000mah over a year or so of very heavy use, as far as I know, this is about average.