Bug 9823

Created attachment 14589 [details]
log files

So,battery information is sometimes not available on this system.
But when it is available, it is correct?
This failure is seen in 2.6.23, and 2.6.24, but no earlier kernels
were tested?

(In reply to comment #2)
> So,battery information is sometimes not available on this system.
> But when it is available, it is correct?

it is like that: once ok once not-ok
that is why it is impossible to use any power management which might i.e hibernate or suspend the system, since it would be doing it in the moment broken acpi wants but not when there is real need for this

depends but I don't know on what
> This failure is seen in 2.6.23, and 2.6.24, but no earlier kernels
> were tested?

this laptop I bought in October 2007, so all kernel since then tested are affected, and I tested: Ubuntu 7.10, Arch, Sabayon and few others
as well as I compiled my own - same problem, also newest 2.6.24 but does not help

Created attachment 14664 [details]
debug patch

Will you please try the debug patch with the boot option of "acpi.debug_layer=0x04000 acpi.debug_level=0x01f"?

Hi, Zygfryd
    Will you please try the attached debug patch ? (using the latest kernel.)
    It is noted that you should enable the ACPI debug function and boot the system with the option of "acpi.debug_layer=0x04000 acpi.debug_level=0x01f". 
    After the system is booted, please execute the command of "cat /proc/acpi/battery/BAT1/info" several times and attach the output of dmesg.
    Thanks. 

The same problem reported here: http://bugzilla.kernel.org/show_bug.cgi?id=9341

the problem is I went back to 2.6.23 as of now

Created attachment 14716 [details]
cat /proc/acpi/battery/BAT1/info output

Created attachment 14717 [details]
dmesg output

I applied the debug patch to 2.6.24-git14. Please find in the attached files the output of both cat /proc/acpi/battery/BAT1/info and dmesg. To catch the problem it  took some time. It was fixed in the BAT1_info.txt. After incorrect values appeared they were incorrected until laptop has been switched off. But with the 2.6.24-git14 I wasn't able reproduced a complete battery info disappearing! It happens very often with vanilla 2.6.24. So I will apply and test the patch from comment #12 of bug 9341. I will inform you the result later.
Thank you!

Created attachment 14718 [details]
The latest dmesg output

I found an additional info in the latest dmesg output. Please find it in the 'dmesg_output_new' file. Maybe it will help.
Thank you!

After applying the patch from comment #12 of bug 9341 I was able reproduce disappearing of battery info:
[root@repair-msi ~]# cat /proc/acpi/battery/BAT1/info
present:                 yes
design capacity:         4400 mAh
last full capacity:      4184 mAh
battery technology:      rechargeable
design voltage:          10800 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1719

serial number:

battery type:            LION

OEM info:                MSI Corp.

[root@repair-msi ~]# cat /proc/acpi/battery/BAT1/info
present:                 no

I don't know is there any relation between the patch and battery info. Previously it made battery info more stable.

Hi, Malashenko
    Will you please try the attached debug patch in comment #4? (using the latest kernel.)
    It is noted that you should enable the ACPI debug function and boot the
system with the option of "acpi.debug_layer=0x040000 acpi.debug_level=0x01f". 
    After the system is booted, please execute the command of "cat
/proc/acpi/battery/BAT1/info" several times and attach the output of dmesg.
    Sorry for my fault in comment #5.
    Thanks.

(In reply to comment #13)
> Hi, Malashenko
>     Will you please try the attached debug patch in comment #4? (using the
> latest kernel.)
>     It is noted that you should enable the ACPI debug function and boot the
> system with the option of "acpi.debug_layer=0x040000 acpi.debug_level=0x01f". 
>     After the system is booted, please execute the command of "cat
> /proc/acpi/battery/BAT1/info" several times and attach the output of dmesg.
>     Sorry for my fault in comment #5.
>     Thanks.
> 

compilation in progress sir ;)

Created attachment 14891 [details]
dmesg acpi/bat/info acpi/bat/state

 uname -a
Linux baboon 2.6.24-ARCH #1 SMP PREEMPT Tue Feb 19 11:02:40 EET 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

 cat /proc/cmdline 
root=/dev/sda7 resume=/dev/sda6 ro  vga=791 acpi.debug_layer=0x040000 acpi.debug_level=0x01f

so far I don't see problems, but gimme 2-3 days heavy testing for this
usually it happens when battery gets completely full and then it disconnects it
so, more time please

Created attachment 14898 [details]
dmesg.log.tar.gz

seems not working - after battery gets fully charged now we see:

 cat /proc/acpi/battery/BAT1/info 
present:                 yes
design capacity:         785 mAh
last full capacity:      12302 mAh
battery technology:      rechargeable
design voltage:          47402 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1719

serial number:           

battery type:            LION

OEM info:                MSI Corp.

 cat /proc/acpi/battery/BAT1/state 
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            488 mA
remaining capacity:      3641 mAh
present voltage:         12569 mV

and dmesg attached

Created attachment 14899 [details]
dmesg.log.tar.gz

ups, previous was when it was "almost" full
now it is full, and messages like this:
15:24:53 papio@baboon:~/myfiles$ cat /proc/acpi/battery/BAT1/state 
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            0 mA
remaining capacity:      3769 mAh
present voltage:         12568 mV
15:38:37 papio@baboon:~/myfiles$ cat /proc/acpi/battery/BAT1/info 
present:                 yes
design capacity:         785 mAh
last full capacity:      12302 mAh
battery technology:      rechargeable
design voltage:          47402 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1719

serial number:           

battery type:            LION

OEM info:                MSI Corp.

15:38:41 papio@baboon:~/myfiles$

see the "last full capacity:"  - due to that acpi -V shows:
15:40:17 papio@baboon:/home/tmp$ acpi -V
     Battery 1: charged, 30%
     Thermal 1: ok, 55.0 degrees C
  AC Adapter 1: on-line
15:41:18 papio@baboon:/home/tmp$ 

and same happens when you divide "remaining capacity" by "last full capacity":
3769 mAh  / 12302 mAh what give exactly 30%

so, I would say: we (you) are close to solution but still needs a bit work
so I'm willing to help as soon as you ask me to implement new patch ;)

Created attachment 14900 [details]
dmesg.log.tar.gz

we are back in problems:

17:30:47 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state 
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            unknown
remaining capacity:      unknown
present voltage:         10000 mV
17:31:39 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info 
present:                 yes
design capacity:         1297 mAh
last full capacity:      12302 mAh
battery technology:      rechargeable
design voltage:          47402 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1719

serial number:           

battery type:            LION

OEM info:                MSI Corp.

17:31:43 papio@baboon:~$ 

dmesg: battery-0309 [00] extract_package       : Battery Extract package :state_offsets is b72a
 battery-0309 [00] extract_package       : Battery Extract package :state is 0
 battery-0309 [00] extract_package       : Battery Extract package :current_now is ffffffff
 battery-0309 [00] extract_package       : Battery Extract package :capacity_now is ffffffff
 battery-0309 [00] extract_package       : Battery Extract package :state_offsets is 2710
 battery-0488 [00] battery_update        : enter acpi_battery_update
 battery-0519 [00] battery_update        : leave acpi_battery_update, in line 519, result is 0
 battery-0309 [00] extract_package       : Battery Extract package :state is 2
 battery-0309 [00] extract_package       : Battery Extract package :current_now is 5f2
 battery-0309 [00] extract_package       : Battery Extract package :capacity_now is 4808
 battery-0309 [00] extract_package       : Battery Extract package :state_offsets is b329
 battery-0488 [00] battery_update        : enter acpi_battery_update
 battery-0500 [00] battery_update        : leave acpi_battery_update, in line 500, battery not present
 battery-0488 [00] battery_update        : enter acpi_battery_update
 battery-0500 [00] battery_update        : leave acpi_battery_update, in line 500, battery not present

Hi, Zygfryd
   Will you please upload the full dmesg output?
   Thanks.

Created attachment 14977 [details]
dmesg and other logs

Created attachment 14978 [details]
dmesg and other logs - now with battery status unknown

but somebody recommended option:  EC_INTR=0
to kernel line in grub and I'm testing it also - so far (lets say half a day) no errors with this parameter regarding battery and acpi

let me try this option for few more days and lets see how it works
on the other hand: to implement your patch support for folders /proc/acpi must be ON in config of kernel while you (kernel dev.) are going now to use /sys 
what is then the reason to use both: /proc/acpi and /sys ?

ups, even with ec_intr=0 it is not working properly, battery "disappearing" again sometimes

Thanks for the info.
From the info in comment #18 we can know that sometimes the design capacity is less than the remaining capacity. 
  >remaining capacity:      3769 mAh
  >present:                 yes
  >design capacity:         785 mAh
  It is uncorrect. And the above info is obtained by calling the AML code (_BST, _BIF), in which the internal EC RAM is accessed.

From the info in commetn #23 we can know that sometimes the returned current_capacity is 0xffffffff and the returned current_current is 0xffffffff. So os reports the message of "unknown state".
   In fact the info is also related with BIOS.

From the info in comment #22 we can know that sometimes the status of the battery is not present. In fact the status of the battery is obtaned by the following AML code:
   >Method (_STA, 0, NotSerialized)              {
   >                        If (MBTS) {
   >                              Return (0x1F)
   >                          } Else{
   >                           Return (0x0F) }
   >                     }
   From the above code the status of the battery is determined by the value of MBTS, which is located in internal EC access region.

   According to the above analysis it seems that the bug is related with EC and there are two possible reasons .
   a. the broken EC firmware ( related with BIOS).
   b. Uncorrect EC I/O access (related with EC driver)
   Maybe a is the mainly root cause.
   
   Will you please upgrade BIOS and see whether the problem still exists?
   
     

that is great comment sir :-)
but let me tell you the story: I already changed BIOS maybe 10 times, 
on MSI web page (http://global.msi.com.tw/index.php?func=downloaddetail&type=bios&maincat_no=135&prod_no=1227) there are 2 BIOS versions: one for XP one for Vista (whatever it means - BIOS is BIOS imho but I might be wrong)
So I tried all BIOS version I could find so far - old, newer, newest, XP, Vista ... etc - always the same problem
One thing: on XP there is no such problem (if this info might help anyway)
So, I don't know what else I can do to solve/help to solve this problem

I can confirm every word of Zygfryd. My GX700 has absolutely the same behavior. I also updated BIOS several times. Unfortunately there wasn't any influence to the problem.

actually MSI forum is now also interested in this problem
we might get people close to MSI to help but we must tell them what we really need from MSI - would you (ykzhao )please explain it somehow to them ?
http://forum.msi.com.tw/index.php?topic=114081.msg863506#new

Hi, Zygfryd
    Thanks for the confirm.
    Will you please try the early stable kernel (2.6.23.1)in order to narrow what causes this bug? ( Please add the boot option of "ec_intr=0 acpi.debug_layer=0x10000 acpi.debug_level=0x1f")
    It is noted that the ACPI debug function should be enabled in kernel configuration. 
    
    Please confirm whether the battery sometimes disappears.
   After the test, please attach the output of dmesg.
   Thanks.
  

Created attachment 15081 [details]
try the custom DSDT

Will you please try the custom the DSDT on the 2.6.23.1 kernel? Please use the boot option described in the comment #20.

How to use the custom DSDT can be found  
http://www.lesswatts.org/projects/acpi/faq.php.
Thanks.

Created attachment 15098 [details]
dmesg

so, I added DSDT you provided here, although it shows warnings during compilation:

  iasl -tc DSDT.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20061109 [Apr 25 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

DSDT.dsl  5312:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5326:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5341:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5356:             Acquire (MUTE, 0x0FFF)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5370:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5385:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

DSDT.dsl  5400:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

ASL Input:  DSDT.dsl - 5641 lines, 174686 bytes, 2338 keywords
AML Output: /home/tmp/dsdt/DSDT.aml - 19532 bytes 684 named objects 1654 executable opcodes

Compilation complete. 0 Errors, 7 Warnings, 0 Remarks, 38 Optimizations

I added output file DSDT.hex to initrd and boot with command line parameters:
 cat /proc/cmdline 
root=/dev/sda2 resume=/dev/sda6 ro vga=791  acpi.debug_layer=0x040000 acpi.debug_level=0x01f

the only problem I have is to compile 2.6.23.1 as I have many modules which would have to be recompiled for that kernel so I stayed with 2.6.24

lets wait now, till problem occurs again - as for now dmesg attached

as you might see there, custom DSDT is in use:

ACPI: Looking for DSDT in initramfs... successfully read 19532 bytes from /DSDT.aml.
ACPI: Table DSDT replaced by host OS
ACPI: DSDT 00000000, 4C4C (r1  17190 17190000        0 INTL 20061109)
ACPI: DSDT override uses original SSDTs unless "acpi_no_auto_ssdt"CPU0: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0a

ok, I did not wait too long:

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

Hi, Zygfryd
    Thanks for the info. I am sorry for the fault in comment #31.
    Please use the boot option described in comment #30 after Custom DSDT is applied.
    Thanks.

Hi, Zygfryd, any updates on this?

(In reply to comment #35)
> Hi, Zygfryd, any updates on this?
> 

cannot move to 2.6.23.1 as my system is on production laptop and many modules would not work then (vboxdr etc)
so only possible way of testing would be:
 uname -a
Linux baboon 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 23 23:23:57 EET 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

Hi!
The problem persists with 2.6.25 and with the latest BIOS update (28.03.2008) for MSI GX700.

same here:
 uname -a
Linux baboon 2.6.25-ARCH #1 SMP PREEMPT Mon Apr 21 23:20:06 EEST 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

and latest BIOS

Hi, Zygfryd
    thanks for the test.
    It seems that the problem still exists even when the latest bios is used. IMO this is still the BIOS bug. More detailed info can be found in comment #26.(Maybe it is related with EC firmware).
    But it is very strange that windows XP can work on it. 
    

Hi!
I can confirm that win XP works without the problem.

Hi, Zygfryd!
It looks like the hint from here: http://ubuntuforums.org/showpost.php?p=4843977&postcount=143 works for me. Please try it to confirm.

correct me if I'm wrong but isn't it same like this:
http://forum.msi.com.tw/index.php?topic=114081.msg876562#msg876562
except it is inside kernel instead of grub kernel parameters ?

I tried - it worked almost ... 20h
then:

09:20:47 papio@baboon:~$ acpi -V
     Thermal 1: ok, 144.0 degrees C
  AC Adapter 1: off-line
09:20:51 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state 
present:                 no
09:21:02 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info 
present:                 no
09:21:07 papio@baboon:~$ cat /proc/acpi/battery/BAT1/
alarm  info   state  
09:21:07 papio@baboon:~$ cat /proc/acpi/ac_adapter/ADP1/state 
state:                   off-line

Created attachment 16991 [details]
patch

Please apply the patch. It solved the problem on my MSI GX700.

compilation in progress... ;-)

so, finally, after less than 24h I got to the point as before:

10:35:39 papio@baboon:~$ acpi -V
     Thermal 1: ok, 144.0 degrees C
  AC Adapter 1: off-line
10:35:41 papio@baboon:~$ cat /proc/acpi/ac_adapter/ADP1/state 
state:                   off-line
10:35:52 papio@baboon:~$ cat /proc/acpi/battery/BAT1/state 
present:                 no
10:36:00 papio@baboon:~$ cat /proc/acpi/battery/BAT1/info 
present:                 no

although EC is in pool mode:

10:37:24 papio@baboon:~$ dmesg | grep EC | grep -v UF
ACPI: EC: Look up EC in DSDT
ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in poll mode
10:37:38 papio@baboon:~$ 

anything else you can do for this guys ? pls

Created attachment 17139 [details]
try the debug patch

Will you please try the debug patch on the latest kernel and see whether the problem still exists?
Please attach the output of dmesg.

compiling sir

Created attachment 17144 [details]
dmesg

compiled, testing, dmesg attached

27h already and no problems (YET)
let me test longer

so, I added to crontab (every minute) the commands:

acpi -V >> acpi.log
cat /proc/acpi/battery/BAT1/state >> acpi.log
cat /proc/acpi/battery/BAT1/info  >> acpi.log

and checking now in acpi.log the presence of any problem I can say: NO problems so far

does it mean anything ? 
how long should I test it to make sure for 100% ?
if it is ok: would it be included in kernel directly or we should live with patching kernel ?

Hi, Zygfryd
    Thanks for your test. 
    From the test it seems that the patch can fix the problem on your machine. In fact the patch fixes an issue related with EC driver, which is not easily reproducible. But unfortunately I don't know what we should test to make sure for 100%. Of course it will be helpful if you can test it for longer time.
    
    IMO the patch is reasonable and I will try to push it into upstream kernel.
    thanks.

Created attachment 17174 [details]
the updated patch

The attached is the updated patch. And I will push it into upstream kernel.

As the problem can be fixed by the patch in comment #53, the bug will be marked as resovled.
Thanks.

Patch is in 2.6.27 upstream now

Hi, reading this bug report, I hoped, that the problem will be fixed on my MSI S271, too.

So I installed 2.6.27-rc7-git, which contains the patch from comment 53 (did check that).

But still I'm not able to get any valuable output out of the acpi system.
The difference is, that the battery is always marked as being present, only the values are wrong:

cat /proc/acpi/battery/BAT1/info
present:                 yes
design capacity:         37008 mAh
last full capacity:      37008 mAh
battery technology:      rechargeable
design voltage:          37008 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1058

serial number:

battery type:            LION

OEM info:                MSI Corp.

cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            unknown
remaining capacity:      unknown
present voltage:         10000 mV

acpi -V
     Thermal 1: ok, 50.0 degrees C
  AC Adapter 1: on-line

acpi -b doesn't show anything.
Is the debug patch from comment 4 still the one to test?
Or is this a completely different issue?

Oh, I should note, that acpi -bs shows:
     Battery 1: slot empty

That is untrue, the battery is definitely there. :)
Also, I should note, that this worked up to 2.6.23 or 2.6.24 (I can bisect it, if it matters).

Hi, Bernd
    I notice that the model of your laptop is MSI271. It is different with MSI700.
    Will you please open a new bug and attach the output of dmesg, acpidump, dmidecode?
    thanks.