Latest working kernel version: actually none previous kernel is working correctly Earliest failing kernel version:2.6.23 Distribution: Arch, Ubuntu Hardware Environment: Laptop MSI GX700 Software Environment: GNU/Linux Problem Description: impossible to manage battery/power on laptop with any kernel Steps to reproduce: I attached log files as outputs of commands: acpi -V acpidump dmesg cat /proc/acpi/...
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.