Bug 5040 - potential IndexField bug :battery charging not indicated-Compaq armada M300
Summary: potential IndexField bug :battery charging not indicated-Compaq armada M300
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Robert Moore
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-10 01:44 UTC by maximilian attems
Modified: 2007-01-15 08:45 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.13-rc5-git3
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg armada laptop (10.16 KB, text/plain)
2005-08-10 01:47 UTC, maximilian attems
Details
acpi dump armada m300 (125.53 KB, text/plain)
2005-08-10 01:49 UTC, maximilian attems
Details
armada m300 dmidecode (14.97 KB, text/plain)
2005-08-10 01:50 UTC, maximilian attems
Details

Description maximilian attems 2005-08-10 01:44:23 UTC
Distribution: Debian Sarge
Hardware Environment: Compaq armada M300 Notbook
Software Environment:
Problem Description: The discharged battery is said to charge at zero rate.

Steps to reproduce: Discharge your battery, plug power cable in.


max@armada:~$ date
Fri Aug  5 13:40:24 CEST 2005
max@armada:~$ acpi -V
     Battery 1: charging, 32%, charging at zero rate - will never fully charge.
     Thermal 1: ok, 29.0 degrees C
  AC Adapter 1: on-line
max@armada:~$ date
Fri Aug  5 13:53:03 CEST 2005
max@armada:~$ acpi -V
     Battery 1: charging, 56%, charging at zero rate - will never fully charge.
     Thermal 1: ok, 33.0 degrees C
  AC Adapter 1: on-line
Comment 1 maximilian attems 2005-08-10 01:47:20 UTC
Created attachment 5575 [details]
dmesg armada laptop
Comment 2 maximilian attems 2005-08-10 01:49:10 UTC
Created attachment 5576 [details]
acpi dump armada m300
Comment 3 maximilian attems 2005-08-10 01:50:25 UTC
Created attachment 5577 [details]
armada m300 dmidecode
Comment 4 Len Brown 2005-08-10 18:42:51 UTC
did this used to work in 2.6.12?
Does it still not work in 2.6.13-rc6?
if so, this may be the ec-burst issue.
Comment 5 maximilian attems 2005-08-11 10:44:27 UTC
no idea about previous state, was not running linux.
had that laptop borrowed for 10 days.
will ask next week to test with latest kernel.
Comment 6 Luming Yu 2005-08-12 00:26:16 UTC
Please try linux-2.6.13-rc6 with patch filed at bug 3851. Pleast test it with  
ec_burst=1 and ec_burst=0.   
Comment 7 maximilian attems 2005-08-17 12:21:52 UTC
tested with linux-2.6.13-rc6 plus the ec-burst patch with boot param ec_burst=1
and ec_burst=0:
no change same output of acpi -V.

in dmesg acpi tells to be in burst or in the polling mode dependent on the
ec_burst param.
Comment 8 Luming Yu 2005-09-05 09:57:24 UTC
I guess aml interpreter has bug when interpreting indexField statement. Because
charging rate shouldn't be 0 when not fully charged. From the _BST, the logic 
is:

1. charging rate !=0 depends on  C0FD !=0
2. C0FD !=0 depends on (Local3 !=0 || Local4 |=0)
3. Local3 !=0 depends on (Local1 and Local2 !=0)
4. Local4 !=0 depends on ((Local0 and Local2' !=0)
5. Local1 !=0 depends on \_SB.C005.C012.C058.C077 !=0
6. Local2 !=0 depends on (Arg0 <<1) !=0  THIS IS TRUE
7. Local0 !=0 depends on \_SB.C005.C012.C058.C067 !=0
8. Local2' !=0 depends on (Arg0 <<1 << 4)!=0 THIS IS TRUE
So, iif (Local1 || Local0) ==0, C0FD will be 0.

Comment 9 Robert Moore 2005-09-06 12:41:00 UTC
It would be very useful to see a trace of the execution of the _BST method 
(with acpi_debug_level = 0x00FFFFFF)
Comment 10 maximilian attems 2005-09-06 12:58:53 UTC
the owner is away this week and next week.
i can try whatever helps you out in 2 weeks.

rebuild against the latest git snapshot at that time with CONFIG_ACPI_DEBUG
optionally apply latest acpi-devel tree and repost what?
how do i get that trace?
is it the acpi dump or the dmidecode or both?
Comment 11 Robert Moore 2006-01-17 12:34:19 UTC
Still need a trace of the execution of _BST, or an example of an interpreter 
failure.
Comment 12 Robert Moore 2006-01-20 13:47:30 UTC
We are investigating a potential discrepancy between the ACPICA interpreter 
and the Windows interpreter concerning IndexFields. I have a patch that *may* 
solve the problem if anyone would like to try it. Will post if anyone is 
interested, otherwise we will close this bug.
Comment 13 maximilian attems 2006-01-21 00:46:58 UTC
i'll get my hand on this laptop next 10 days will test latest linus, latest acpi.
and test any patch that i'm pointed too.
i'm confused which trace you need, but i'll repost aboves attachments with
CONFIG_ACPI_DEBUG.
Comment 14 Robert Moore 2006-01-23 14:26:34 UTC
I can't give you a patch to the actual Linux code, but here is the proposed 
change.

In exprep.c, ex_prep_field_value, change this code:

obj_desc->index_field.value  = (u32)
	(info->field_bit_position / ACPI_MUL_8 (
			  obj_desc->field.access_byte_width));

to:

obj_desc->index_field.value = (u32) ACPI_DIV_8 (info->field_bit_position);
Comment 15 Robert Moore 2006-02-17 10:09:55 UTC
This code has been integrated into release 20060217
Comment 16 Len Brown 2007-01-15 08:45:40 UTC
ACPICA 20060707 shipped in Linux-2.6.18

Note You need to log in before you can comment on or make changes to this bug.