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
Created attachment 5575 [details] dmesg armada laptop
Created attachment 5576 [details] acpi dump armada m300
Created attachment 5577 [details] armada m300 dmidecode
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.
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.
Please try linux-2.6.13-rc6 with patch filed at bug 3851. Pleast test it with ec_burst=1 and ec_burst=0.
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.
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.
It would be very useful to see a trace of the execution of the _BST method (with acpi_debug_level = 0x00FFFFFF)
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?
Still need a trace of the execution of _BST, or an example of an interpreter failure.
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.
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.
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);
This code has been integrated into release 20060217
ACPICA 20060707 shipped in Linux-2.6.18