Bug 14446 - battery status info broken/useless in 2.6.32-rc3 - MSI PR200 (possibly others, too)
Summary: battery status info broken/useless in 2.6.32-rc3 - MSI PR200 (possibly others...
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Zhang Rui
URL:
Keywords:
: 14740 14764 (view as bug list)
Depends on:
Blocks: 13615
  Show dependency tree
 
Reported: 2009-10-20 08:25 UTC by Eddy Petrișor
Modified: 2011-06-08 05:51 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.32-rc3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
debug patch (625 bytes, patch)
2009-10-20 21:48 UTC, Alexey Starikovskiy
Details | Diff
syslog of 2.6.32-rc3 with debug patch (904.21 KB, text/plain)
2009-10-21 06:35 UTC, Eddy Petrișor
Details
dmidecode output (8.02 KB, text/plain)
2009-10-22 07:46 UTC, Eddy Petrișor
Details
debug patch #2 (758 bytes, patch)
2009-10-22 09:16 UTC, Alexey Starikovskiy
Details | Diff
syslog of 2.6.32-rc3 with first detection patch (638.54 KB, text/plain)
2009-10-23 06:38 UTC, Eddy Petrișor
Details
syslog of 2.6.32-rc3 + detection patch (94.31 KB, text/plain)
2009-10-26 07:16 UTC, Eddy Petrișor
Details
fix MSI detection (1.34 KB, patch)
2009-10-26 11:28 UTC, Alexey Starikovskiy
Details | Diff
fix MSI detection (1.35 KB, patch)
2009-10-26 23:17 UTC, Alexey Starikovskiy
Details | Diff
syslog with some ACPI debug (632.24 KB, text/plain)
2010-03-05 12:06 UTC, Mihail Kasadjikov
Details
dmidecode output for MSI S271 (13.38 KB, text/plain)
2010-03-05 12:30 UTC, Mihail Kasadjikov
Details
dmesg for MSI S271 (39.51 KB, text/plain)
2010-03-05 13:52 UTC, Mihail Kasadjikov
Details
dmesg for 2.6.37 at MSI S271 (73.78 KB, text/plain)
2011-01-18 12:05 UTC, Mihail Kasadjikov
Details
dmidecode for 2.6.37 at MSI S271 (13.38 KB, text/plain)
2011-01-18 12:06 UTC, Mihail Kasadjikov
Details
kern.log for 2.6.37 at MSI S271 (231.24 KB, text/plain)
2011-01-18 12:07 UTC, Mihail Kasadjikov
Details

Description Eddy Petrișor 2009-10-20 08:25:04 UTC
In 2.6.26 the battery status information was updated with a lag, but it was correct, given enough time.

In 2.6.30 the battery information on my laptop MSI PR200 was properly updated, read and I had no problems.


Now, in 2.6.32-rc3 the battery information is so broken that, even when the battery is full and laptop is on AC, ACPI claims that the battery is empty and needs more time to recharge.


For instance, now the battery is full and the laptop is on AC, but this is what happens:

0 eddy@heidi ~ $ acpi
     Battery 0: Charging, 0%, 02:10:12 until charged, design capacity 5200 mAh
0 eddy@heidi ~ $ uname -a
Linux heidi 2.6.32-rc3-heidi #1 SMP Mon Oct 12 01:53:56 EEST 2009 x86_64 GNU/Linux


This is even worse since because of this misreading of information, when on battery there is no way to surely know when the battery rans out and the laptop simply is abruptly turned off, just as it would happen if the battery was simply removed (no warning to applications such as gnome-power-manager).



Please tell me what other information I can provide to help fixing this regression.
Comment 1 Eddy Petrișor 2009-10-20 08:47:14 UTC
You might want to look into the history of bug #12011 for more information on the history of the problems with ACPI on other MSI laptops.
Comment 2 Alexey Starikovskiy 2009-10-20 09:22:10 UTC
Eddy,
Could you please attach dmesg?
what happens if you do cat of /proc/acpi/battery/*/*?
Comment 3 Eddy Petrișor 2009-10-20 10:06:21 UTC
(In reply to comment #2)
> Eddy,
> Could you please attach dmesg?

There is already a dmesg from this kernel at http://bugzilla.kernel.org/attachment.cgi?id=23466

this was obtained in a boot-hibernate-resume sequence.

Please tell me if you need a cleaner dmesg or if I have to try some other commands to trigger some behaviour which isn't clear from that dmesg.

> what happens if you do cat of /proc/acpi/battery/*/*?


heidi:/home/eddy# cat /proc/acpi/battery/*/*
cat: /proc/acpi/battery/*/*: No such file or directory
Comment 4 Eddy Petrișor 2009-10-20 20:26:10 UTC
And the module is loaded...

0 eddy@heidi ~ $ lsmod | grep battery
battery                 5590  0 
0 eddy@heidi ~ $ cat /proc/acpi/battery/*/*
cat: /proc/acpi/battery/*/*: No such file or directory
Comment 5 Alexey Starikovskiy 2009-10-20 21:48:38 UTC
Created attachment 23481 [details]
debug patch

Please apply this patch and send a dmesg with the boot sequence in it... M/b you will need to get it from /var/log/messages or something.
Comment 6 Eddy Petrișor 2009-10-21 06:35:06 UTC
Created attachment 23485 [details]
syslog of 2.6.32-rc3 with debug patch

I haven't found the 'Detected MSI hardware, enabling workarounds.' message in the syslog, but I see lots of 'ACPI EC' messages, so I assume the hardware isn't properly detected. Please tell me if I have to do anything else.
Comment 7 Alexey Starikovskiy 2009-10-21 23:39:42 UTC
Do you have dmidecode output handy? Please attach it here.
Comment 8 Eddy Petrișor 2009-10-22 07:42:32 UTC
Just as a helper note, I installed the 2.6.31 kernel prepared by Debian for experimental and I am not experiencing these issues:

0 eddy@heidi ~ $ acpi
     Battery 0: Full, 100%, design capacity 5200 mAh
0 eddy@heidi ~ $ uname -r
2.6.31-trunk-amd64


OTOH, I am unsure what patches are applied, but the policy of the kernel team is to not diverge too much from the upstream and only to accept patches which are/were/will be accepted upstream.

If this proves useful I could try to build my own kernel from upstream sources.
Comment 9 Eddy Petrișor 2009-10-22 07:46:18 UTC
Created attachment 23492 [details]
dmidecode output

I got this while running the 2.6.31-trunk-amd64 kernel mentioned before, but judging from dmidecode's man page this should be irrelevant.
Comment 10 Alexey Starikovskiy 2009-10-22 09:16:15 UTC
Created attachment 23493 [details]
debug patch #2

Eddy, please check if this patch makes your MSI detected.
Comment 11 Eddy Petrișor 2009-10-23 06:38:55 UTC
Created attachment 23495 [details]
syslog of 2.6.32-rc3 with first detection patch

There is no change in the behaviour with the new patch.

0 eddy@heidi ~/usr/share/doc/debug_linux/battery_issues $ acpi
     Battery 0: Unknown, 0%, rate information unavailable, design capacity 5200 mAh
0 eddy@heidi ~/usr/share/doc/debug_linux/battery_issues $ uname -r
2.6.32-rc3-heidi


I'm going to try to see if I can bisect to identify the bug introducing the regression, but I please don't stop working on the issue from your end :-) .
Comment 12 Eddy Petrișor 2009-10-23 06:40:11 UTC
I meant "... identify the commit introducing the regression ..."
Comment 13 Alexey Starikovskiy 2009-10-23 13:52:27 UTC
Eddy, it seems you still use old patch. In new patch "#define DEBUG" is left commented out.
Comment 14 Eddy Petrișor 2009-10-26 07:10:53 UTC
(In reply to comment #13)
> Eddy, it seems you still use old patch. In new patch "#define DEBUG" is left
> commented out.

I tried to apply the new patch over the old one and that what was the result.

Now I am running 2.6.32-rc3+the second patch and the acpi battery information is still missing:

0 eddy@heidi ~/usr/share/doc/debug_linux/battery_issues $ acpi
     Battery 0: Unknown, 0%, rate information unavailable, design capacity 5200 mAh
Comment 15 Eddy Petrișor 2009-10-26 07:16:54 UTC
Created attachment 23525 [details]
syslog of 2.6.32-rc3 + detection patch

There is no mention of MSI in a context which one would expect, but only irq related messages.


OTOH, I am continuing the bisection:

0 eddy@heidi ~/usr/src/linux/linux-2.6 $ git bisect log 
git-bisect start
# good: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31
git-bisect good 74fca6a42863ffacaf7ba6f1936a9f228950f657
# bad: [a6b64111c9c287d899d19b91511ccee87516dbba] try detect
git-bisect bad a6b64111c9c287d899d19b91511ccee87516dbba
# skip: [c8a429a465f9aaabe7fc7ddf5f34ff6dd188a68f] Staging: hv: remove timer wrapper functions
git-bisect skip c8a429a465f9aaabe7fc7ddf5f34ff6dd188a68f
# good: [578f2938a43f83988f6edab86cff487889b4ef58] Staging: HTC Dream: Makefile glue
git-bisect good 578f2938a43f83988f6edab86cff487889b4ef58
# good: [2f66a68f3fac2e94da360c342ff78ab45553f86c] page-allocator: change migratetype for all pageblocks within a high-order page during __rmqueue_fallback
git-bisect good 2f66a68f3fac2e94da360c342ff78ab45553f86c
# good: [142597dbbd8a1d516af3dacfa00037f21612e865] powerpc: Cleanup linker script using new linker script macros.
git-bisect good 142597dbbd8a1d516af3dacfa00037f21612e865
# good: [6053bbf7bbdbb2c94547f830ad07636c17d7024e] cnic: Fix NETDEV_UP event processing.
git-bisect good 6053bbf7bbdbb2c94547f830ad07636c17d7024e
# good: [0d9df2515dbceb67d343c0f10fd3ff218380d524] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes
git-bisect good 0d9df2515dbceb67d343c0f10fd3ff218380d524
# good: [4388eb11351660c7688a4756aa6da99bfb4bc129] spi-imx: no need to assert bits_per_word being initialized
git-bisect good 4388eb11351660c7688a4756aa6da99bfb4bc129
Comment 16 Alexey Starikovskiy 2009-10-26 09:13:53 UTC
Eddy,
I think you may safely limit bisect to drivers/acpi/ec.c ... Detection of MSI notebooks have changed, and I still don't see it working even with second patch.
Could it be that your syslog does not have debug statements enabled?
Comment 17 Eddy Petrișor 2009-10-26 10:58:36 UTC
0 eddy@heidi /etc $ grep debug syslog.conf -A 2
*.=debug;\
	auth,authpriv.none;\
	news.none;mail.none	-/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
--
#	*.=debug;*.=info;\
#	*.=notice;*.=warn	/dev/tty8

--
	*.=debug;*.=info;\
	*.=notice;*.=warn	|/dev/xconsole

0 eddy@heidi /etc $ grep -i msi /var/log/debug
Oct 26 08:55:33 heidi kernel: [    0.475234] pcieport-driver 0000:00:1c.0: irq 24 for MSI/MSI-X
Oct 26 08:55:33 heidi kernel: [    0.475480] pcieport-driver 0000:00:1c.1: irq 25 for MSI/MSI-X
Oct 26 08:55:33 heidi kernel: [    0.475725] pcieport-driver 0000:00:1c.2: irq 26 for MSI/MSI-X
Oct 26 08:55:33 heidi kernel: [    0.967620] r8169 0000:03:00.0: irq 27 for MSI/MSI-X
Oct 26 08:55:34 heidi kernel: [    7.607524] iwlagn 0000:02:00.0: irq 28 for MSI/MSI-X
Oct 26 08:55:49 heidi kernel: [   39.908688] pci 0000:00:02.0: irq 29 for MSI/MSI-X
Comment 18 Alexey Starikovskiy 2009-10-26 11:28:45 UTC
Created attachment 23532 [details]
fix MSI detection

Eddy, I think, I've found a problem with detection of MSI hardware, please check.
Comment 19 Eddy Petrișor 2009-10-26 22:50:17 UTC
(In reply to comment #18)
> Created an attachment (id=23532) [details]
> fix MSI detection
> 
> Eddy, I think, I've found a problem with detection of MSI hardware, please
> check.

The parentheses are way unbalanced after this patch...
Comment 20 Alexey Starikovskiy 2009-10-26 23:17:20 UTC
Created attachment 23541 [details]
fix MSI detection

yes, my fault... please try this one instead...
Comment 21 Eddy Petrișor 2009-10-27 01:25:33 UTC
(In reply to comment #20)
> Created an attachment (id=23541) [details]
> fix MSI detection
> 
> yes, my fault... please try this one instead...

I figure myself those were the places where the opening parentheses. Will answer tomorrow.
Comment 22 Eddy Petrișor 2009-10-27 07:38:40 UTC
On the bisect front I have this weird behaviour:

On battery:

0 eddy@heidi ~ $ acpi
     Battery 0: Discharging, 99%, 72:18:15 remaining, design capacity 5200 mAh

On AC:

0 eddy@heidi ~ $ acpi
     Battery 0: Unknown, 99%, design capacity 5200 mAh


0 eddy@heidi ~ $ uname -r
2.6.32-rc2-g8a0382f6-heidi
Comment 23 Alexey Starikovskiy 2009-10-27 12:08:45 UTC
I think this is regression from this patch 56f382a08722186623400180adbb9d1be1721cee.
Comment 24 Eddy Petrișor 2009-10-27 20:11:20 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > Created an attachment (id=23541) [details] [details]
> > fix MSI detection
> > 
> > yes, my fault... please try this one instead...
> 
> I figure myself those were the places where the opening parentheses. Will
> answer tomorrow.

(In reply to comment #20)
> Created an attachment (id=23541) [details]
> fix MSI detection
> 
> yes, my fault... please try this one instead...

0 eddy@heidi ~ $ grep -i msi /var/log/syslog
Oct 27 21:54:31 heidi kernel: [    0.156206] ACPI: EC: Detected MSI hardware, enabling workarounds.
Oct 27 21:54:31 heidi kernel: [    0.490178] pcieport-driver 0000:00:1c.0: irq 24 for MSI/MSI-X
Oct 27 21:54:31 heidi kernel: [    0.490421] pcieport-driver 0000:00:1c.1: irq 25 for MSI/MSI-X
Oct 27 21:54:31 heidi kernel: [    0.490658] pcieport-driver 0000:00:1c.2: irq 26 for MSI/MSI-X
Oct 27 21:54:31 heidi kernel: [    0.941369] r8169 0000:03:00.0: irq 27 for MSI/MSI-X
Oct 27 21:54:31 heidi kernel: [    7.266861] iwlagn 0000:02:00.0: irq 28 for MSI/MSI-X
Oct 27 21:54:46 heidi kernel: [   40.867076] pci 0000:00:02.0: irq 29 for MSI/MSI-X


Still on AC there are some issues:
0 eddy@heidi ~ $ acpi
     Battery 0: Unknown, 99%, design capacity 5200 mAh
Comment 25 Alexey Starikovskiy 2009-10-27 20:15:31 UTC
for your remaining issue, please try to revert patch mentioned in #23
Comment 26 Alexey Starikovskiy 2009-10-27 20:16:27 UTC
and do 'grep . /proc/acpi/battery/*/*' beforehand
Comment 27 Eddy Petrișor 2009-10-28 20:22:01 UTC
(In reply to comment #26)
> and do 'grep . /proc/acpi/battery/*/*' beforehand

OK, I reverted that commit and it works indeed and detects the state properly on AC, the AC disconnection happens fast, as it should.

0 eddy@heidi ~ $ acpi
     Battery 0: Full, 98%, design capacity 5200 mAh
0 eddy@heidi ~ $ uname -r
2.6.32-rc3-heidi


But there is still this issue (while I am unsure this is indeed necessary since gnome-power-manager doesn't seem to mind:

0 eddy@heidi ~ $ grep . /proc/acpi/battery/*/*
grep: /proc/acpi/battery/*/*: No such file or directory
Comment 28 Eddy Petrișor 2009-10-28 20:24:05 UTC
This is the version I am running 2.6.32-rc3 + the detection patch, paren fixes and the revert :

0 eddy@heidi ~/usr/src/linux/linux-2.6 $ git log --pretty=oneline --max-count=4
ecfcc467c28a55bb976e2c949b11deeeab5b6a2a Revert "battery: don't assume we are fully charged when not charging o
a094afc7c025292ae3c6208264e10c1daf368309 fix unbalanced parenthesis
82fabab1e6bc838d984ca75bffae35c56eccd3f1 MSI strings should be ORed, not ANDed.
374576a8b6f865022c0fd1ca62396889b23d66dd Linux 2.6.32-rc3
Comment 29 Eddy Petrișor 2009-10-28 20:25:47 UTC
(In reply to comment #26)
> and do 'grep . /proc/acpi/battery/*/*' beforehand

Oh, and this didn't yield any results with neither of the kernels.
Comment 30 Alexey Starikovskiy 2009-10-28 20:38:49 UTC
presence of /proc files is controlled by config variable CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROCFS_POWER
Comment 31 Eddy Petrișor 2009-11-09 20:24:45 UTC
(In reply to comment #30)
> presence of /proc files is controlled by config variable CONFIG_ACPI_PROCFS
> and
> CONFIG_ACPI_PROCFS_POWER

Sorry for the really late reply, I was busy with some RL stuff.

I selected that configuration option (iirc, is marked obsolete) and got the expected data:

0 eddy@heidi ~ $ cat /proc/acpi/battery/*/*
alarm:                   unsupported
present:                 yes
design capacity:         5200 mAh
last full capacity:      5019 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 0 mAh
design capacity low:     0 mAh
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            MS-1221

serial number:           

battery type:            LION

OEM info:                MSI Corp.

present:                 yes
capacity state:          ok
charging state:          charged
present rate:            0 mA
remaining capacity:      5019 mAh
present voltage:         16760 mV
Comment 32 Alexey Starikovskiy 2009-12-08 14:57:57 UTC
*** Bug 14764 has been marked as a duplicate of this bug. ***
Comment 33 Len Brown 2009-12-16 06:07:11 UTC
Alexey,
is there a patch proposed for upstream here?
Comment 34 Unnamed_Hero 2009-12-18 04:53:54 UTC
Lastest 2.6.32.1 ships without patch...After patching battery status works great.
Comment 35 Alexey Starikovskiy 2009-12-18 07:37:57 UTC
Len, patch in comment #20 should go up.
Comment 36 Len Brown 2009-12-22 07:46:12 UTC
patch in comment #20 applied to acpi tree
I've marked it with cc: stable@kernel.org,
so it should go to 2.6.32.stable too onces it is upstream.
Comment 37 Len Brown 2009-12-26 04:37:46 UTC
shipped in linux-2.6.33-rc2 and sent to .32.stable

closed.
Comment 38 Leonid Podolny 2009-12-30 11:35:45 UTC
*** Bug 14740 has been marked as a duplicate of this bug. ***
Comment 39 Tom-Steve Watzke 2010-01-07 14:37:38 UTC
Please reopen this bug to complete the collection of MSI Detected Hardware (this ec_dmi_table). I just tested this patch for my notebook, which failed due to another variant of writing the manufacturer's name. :-/

Complete list as far as I know:
- Micro-Star
- MICRO-Star
- MICRO-STAR

Concluding ... I added the entry in this table (see patch) for MICRO-STAR and it worked for me.
Comment 40 Len Brown 2010-01-20 05:29:53 UTC
oh i hate the DMI maintenance game.

Tom,
did you put MICRO-STAR as DMI_BIOS_VENDOR,
or as DMI_SYS_VENDOR?
Comment 41 Len Brown 2010-01-20 05:31:38 UTC
Tom, probably best to just attach the output from dmidecode
Comment 42 Tom-Steve Watzke 2010-01-20 09:23:33 UTC
Instead of attaching the dmidecode I just print the relevant section.
(Other "Manufacturer:" keys are followed by "Notebook" or "Manufacturer<i>" where <i> is an integer)

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
        Manufacturer: MICRO-STAR INT'L CO.,LTD.
        Type: Notebook
        Lock: Not Present
        Version: To Be Filled By O.E.M.
        [...]

Thus I added the following ec_dmi_table entry:

  {
  ec_flag_msi, "MSI hardware", {
  DMI_MATCH(DMI_CHASSIS_VENDOR, "MICRO-STAR")}, NULL},

Finally I added it neither as DMI_BIOS_VENDOR nor DMI_SYS_VENDOR, but DMI_CHASSIS_VENDOR.

Best Regards
Comment 43 Mihail Kasadjikov 2010-03-05 12:06:51 UTC
Created attachment 25364 [details]
syslog with some ACPI debug

I have a MSI S271 and have this problem too.
I have created a simple bash script for collect system logs when the battery info is corrupting.

hamer@hamer13:~$ uname -a
Linux hamer13 2.6.33-hamer #1 SMP Sat Feb 27 14:39:55 EET 2010 i686 GNU/Linux

hamer@hamer13:~$ cat batt_test.sh
#!/bin/sh
dt=$(date +"%Y-%m-%d_%H-%M-%S")
batt_dir=/home/hamer/tmp/batt_test_$dt
asd=$(cat /sys/class/power_supply/BAT1/uevent | \
 grep POWER_SUPPLY_CURRENT_NOW | \
 cut -d "=" -f 2)
if [ "-1000" = "$asd" ]
then
 echo $dt > $lock_file
 echo "Battery information is broken."
 mkdir $batt_dir
 cd $batt_dir
 cat /sys/class/power_supply/BAT1/uevent 2>&1 >batt_sys.txt
 cat /proc/acpi/battery/*/* 2>&1 >batt_proc.txt
 cp /var/log/debug .
 cp /var/log/syslog .
 cp /var/log/kern.log .
 cp /var/log/daemon.log .
 cp /var/log/messages .
 cp /var/log/dmesg .
fi

hamer@hamer13:~$ crontab -l
# m h  dom mon dow   command
*/2 * * * * /home/hamer/batt_test.sh

Also I have increased the debug level for ACPI system:

hamer13:~# echo 0x00860006 > /sys/module/acpi/parameters/debug_layer
hamer13:~# echo 0xac02c504 > /sys/module/acpi/parameters/debug_level
hamer13:~# cat /sys/module/acpi/parameters/debug_layer
Description                     Hex        SET
ACPI_UTILITIES                  0x00000001 [ ]
ACPI_HARDWARE                   0x00000002 [*]
ACPI_EVENTS                     0x00000004 [*]
ACPI_TABLES                     0x00000008 [ ]
ACPI_NAMESPACE                  0x00000010 [ ]
ACPI_PARSER                     0x00000020 [ ]
ACPI_DISPATCHER                 0x00000040 [ ]
ACPI_EXECUTER                   0x00000080 [ ]
ACPI_RESOURCES                  0x00000100 [ ]
ACPI_CA_DEBUGGER                0x00000200 [ ]
ACPI_OS_SERVICES                0x00000400 [ ]
ACPI_CA_DISASSEMBLER            0x00000800 [ ]
ACPI_COMPILER                   0x00001000 [ ]
ACPI_TOOLS                      0x00002000 [ ]
ACPI_BUS_COMPONENT              0x00010000 [ ]
ACPI_AC_COMPONENT               0x00020000 [*]
ACPI_BATTERY_COMPONENT          0x00040000 [*]
ACPI_BUTTON_COMPONENT           0x00080000 [ ]
ACPI_SBS_COMPONENT              0x00100000 [ ]
ACPI_FAN_COMPONENT              0x00200000 [ ]
ACPI_PCI_COMPONENT              0x00400000 [ ]
ACPI_POWER_COMPONENT            0x00800000 [*]
ACPI_CONTAINER_COMPONENT        0x01000000 [ ]
ACPI_SYSTEM_COMPONENT           0x02000000 [ ]
ACPI_THERMAL_COMPONENT          0x04000000 [ ]
ACPI_MEMORY_DEVICE_COMPONENT    0x08000000 [ ]
ACPI_VIDEO_COMPONENT            0x10000000 [ ]
ACPI_PROCESSOR_COMPONENT        0x20000000 [ ]
ACPI_ALL_DRIVERS                0xFFFF0000 [-]
--
debug_layer = 0x00860006 ( * = enabled)

hamer13:~# cat /sys/module/acpi/parameters/debug_level
Description                     Hex        SET
ACPI_LV_INIT                    0x00000001 [ ]
ACPI_LV_DEBUG_OBJECT            0x00000002 [ ]
ACPI_LV_INFO                    0x00000004 [*]
ACPI_LV_INIT_NAMES              0x00000020 [ ]
ACPI_LV_PARSE                   0x00000040 [ ]
ACPI_LV_LOAD                    0x00000080 [ ]
ACPI_LV_DISPATCH                0x00000100 [*]
ACPI_LV_EXEC                    0x00000200 [ ]
ACPI_LV_NAMES                   0x00000400 [*]
ACPI_LV_OPREGION                0x00000800 [ ]
ACPI_LV_BFIELD                  0x00001000 [ ]
ACPI_LV_TABLES                  0x00002000 [ ]
ACPI_LV_VALUES                  0x00004000 [*]
ACPI_LV_OBJECTS                 0x00008000 [*]
ACPI_LV_RESOURCES               0x00010000 [ ]
ACPI_LV_USER_REQUESTS           0x00020000 [*]
ACPI_LV_PACKAGE                 0x00040000 [ ]
ACPI_LV_ALLOCATIONS             0x00100000 [ ]
ACPI_LV_FUNCTIONS               0x00200000 [ ]
ACPI_LV_OPTIMIZATIONS           0x00400000 [ ]
ACPI_LV_MUTEX                   0x01000000 [ ]
ACPI_LV_THREADS                 0x02000000 [ ]
ACPI_LV_IO                      0x04000000 [*]
ACPI_LV_INTERRUPTS              0x08000000 [*]
ACPI_LV_AML_DISASSEMBLE         0x10000000 [ ]
ACPI_LV_VERBOSE_INFO            0x20000000 [*]
ACPI_LV_FULL_TABLES             0x40000000 [ ]
ACPI_LV_EVENTS                  0x80000000 [*]
--
debug_level = 0xAC02C504 (* = enabled)

So, the script has catched the battery info corruption at "Mar  5 09:58:01".
In attached syslog the first "batt_test" entry at "Mar  5 09:56:01" is PASSED test, the second entry at "Mar  5 09:58:01" - the FAILED test. Between this two tests something happend.
Comment 44 Mihail Kasadjikov 2010-03-05 12:16:11 UTC
Addendum to previous comments:

hamer@hamer13:~$ cat /proc/cmdline
root=UUID=c313c8e7-56a0-4dea-ab89-48054e5521df ro reboot=b pci=use_crs vga=0x0303 quiet ipv6.disable=1

If you need logs with other debugging options, or other parameters of the kernel I can do it.
Comment 45 Mihail Kasadjikov 2010-03-05 12:30:20 UTC
Created attachment 25365 [details]
dmidecode output for MSI S271
Comment 46 Mihail Kasadjikov 2010-03-05 13:52:41 UTC
Created attachment 25367 [details]
dmesg for MSI S271
Comment 47 Mihail Kasadjikov 2010-03-05 16:40:24 UTC
Parsing syslog I has noticed that quantity of calls "hw_read/evgpe-0445/evevent-0249" at the moment of failure and after it was suspiciously small. Maybe for any reasons EC ceases to produce the complete report of the battery status and it needs to be initialized anew?

For example, the fragment of parsing /var/log/syslog:
hamer@hamer13:~/tmp/batt_test_2010-03-05_09-58-01$ cat /var/log/syslog | grep evgpe- | ./report.awk
...
Mar 5 09:54:01  128     ============-
Mar 5 09:54:16  148     ==============-
Mar 5 09:54:46  160     ================
Mar 5 09:55:16  148     ==============-
Mar 5 09:55:46  164     ================
Mar 5 09:56:01  144     ==============
Mar 5 09:56:16  172     =================
Mar 5 09:56:46  160     ================
Mar 5 09:57:16  156     ===============-
Mar 5 09:57:46  16      =-
Mar 5 09:58:01  12      =
Mar 5 09:58:16  16      =-
Mar 5 09:58:46  24      ==
Mar 5 09:59:16  24      ==
Mar 5 09:59:46  24      ==
Mar 5 10:00:01  8       -
...
Comment 48 Zhang Rui 2010-10-22 03:08:30 UTC
does the problem still exist in the latest upstream kernel? say 2.6.35 or 2.6.36-rc?
Comment 49 Leonid Podolny 2010-10-22 17:27:49 UTC
I'm not the original reporter, but I own a PR200 and used to have this problem, and now everything seems to be OK (after Bug 14740 was resolved).
Comment 50 Leonid Podolny 2010-10-22 17:29:14 UTC
(In reply to comment #49)
> I'm not the original reporter, but I own a PR200 and used to have this
> problem,
> and now everything seems to be OK (after Bug 14740 was resolved).

Sorry, the bug number is wrong, but nevertheless, it works now.
Comment 51 Eddy Petrișor 2010-10-22 22:26:59 UTC
(In reply to comment #48)
> does the problem still exist in the latest upstream kernel? say 2.6.35 or
> 2.6.36-rc?

I stopped having the issue a while back, and right at comment #31 I said I got the expected result. Now I am running a 2.6.32 debian kernel which does not have this issue, but if you think there are reasons it should be present in 2.6.35 or later, ples let me know and I'll test.

OTOH, I still have #12878 on this machine.
Comment 52 Zhang Rui 2010-10-25 00:21:09 UTC
Close this bug as it seems to be fixed in the upstream kernel.
please feel free to re-open it at any time if the problem can be reproduced in the latest mainline kernel.
Comment 53 Mihail Kasadjikov 2010-11-09 01:09:56 UTC
Sorry for the late reply,
The problem still exists on MSI S271... :-(

The info from /sys/class/power_supply/BAT1/*
$ for asd in /sys/class/power_supply/BAT1/*; \
 do [ -f $asd ] && \
 echo -n "$asd=" && cat $asd; done

Normal state: msi_1.txt
After some minutes: msi_2.txt

$ diff -ub msi_1.txt msi_2.txt
--- msi_1.txt   2010-11-09 03:05:27.000000000 +0200
+++ msi_2.txt   2010-11-09 03:05:54.000000000 +0200
@@ -1,29 +1,29 @@
 /sys/class/power_supply/BAT1/alarm=0
 /sys/class/power_supply/BAT1/charge_full=2139000
 /sys/class/power_supply/BAT1/charge_full_design=4400000
-/sys/class/power_supply/BAT1/charge_now=1744000
-/sys/class/power_supply/BAT1/current_now=897000
+/sys/class/power_supply/BAT1/charge_now=-1000
+/sys/class/power_supply/BAT1/current_now=-1000
 /sys/class/power_supply/BAT1/cycle_count=0
 /sys/class/power_supply/BAT1/manufacturer=MSI Corp.
 /sys/class/power_supply/BAT1/model_name=MS-1058
 /sys/class/power_supply/BAT1/present=1
 /sys/class/power_supply/BAT1/serial_number=
-/sys/class/power_supply/BAT1/status=Charging
+/sys/class/power_supply/BAT1/status=Unknown
 /sys/class/power_supply/BAT1/technology=Unknown
 /sys/class/power_supply/BAT1/type=Battery
 /sys/class/power_supply/BAT1/uevent=POWER_SUPPLY_NAME=BAT1
-POWER_SUPPLY_STATUS=Charging
+POWER_SUPPLY_STATUS=Unknown
 POWER_SUPPLY_PRESENT=1
 POWER_SUPPLY_TECHNOLOGY=Unknown
 POWER_SUPPLY_CYCLE_COUNT=0
 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000
-POWER_SUPPLY_VOLTAGE_NOW=16711000
-POWER_SUPPLY_CURRENT_NOW=897000
+POWER_SUPPLY_VOLTAGE_NOW=10000000
+POWER_SUPPLY_CURRENT_NOW=-1000
 POWER_SUPPLY_CHARGE_FULL_DESIGN=4400000
 POWER_SUPPLY_CHARGE_FULL=2139000
-POWER_SUPPLY_CHARGE_NOW=1744000
+POWER_SUPPLY_CHARGE_NOW=-1000
 POWER_SUPPLY_MODEL_NAME=MS-1058
 POWER_SUPPLY_MANUFACTURER=MSI Corp.
 POWER_SUPPLY_SERIAL_NUMBER=
 /sys/class/power_supply/BAT1/voltage_min_design=14800000
-/sys/class/power_supply/BAT1/voltage_now=16711000
+/sys/class/power_supply/BAT1/voltage_now=10000000
Comment 54 Mihail Kasadjikov 2010-11-09 01:12:33 UTC
Please reopen the bug.
Comment 55 Zhang Rui 2010-11-09 01:19:46 UTC
Mihail, can you please verify if the problem you met is a duplicate of bug #14461?
Comment 56 Zhang Rui 2010-11-09 01:24:15 UTC
oh.sorry, I just saw your post.
Comment 57 Len Brown 2011-01-18 06:40:12 UTC
Mihail
Please test 2.6.37 and attach the complete dmesg.
Also please attach the complete output from dmidecode
for your MSI S271.
Comment 58 Mihail Kasadjikov 2011-01-18 12:03:10 UTC
Joey Lee found that the problem appears after query from EC by 0x11. (ex. lcd_level)

root@hamer13:~/test_2# date && \
echo 0x00860006 > /sys/module/acpi/parameters/debug_layer && \
echo 0xac02c504 > /sys/module/acpi/parameters/debug_level && \
sleep 2 && cat /sys/class/power_supply/BAT1/uevent && \
sleep 2 && cat /sys/devices/platform/msi-laptop-pf/lcd_level && \
sleep 2 && cat /sys/class/power_supply/BAT1/uevent && \
cp /var/log/dmesg . && cp /var/log/kern.log . && cp /var/log/syslog .

Tue Jan 18 12:14:32 EET 2011

POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000
POWER_SUPPLY_VOLTAGE_NOW=16392000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=4400000
POWER_SUPPLY_CHARGE_FULL=2139000
POWER_SUPPLY_CHARGE_NOW=2020000
POWER_SUPPLY_MODEL_NAME=MS-1058
POWER_SUPPLY_MANUFACTURER=MSI Corp.
POWER_SUPPLY_SERIAL_NUMBER=

1

POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000
POWER_SUPPLY_VOLTAGE_NOW=10000000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4400000
POWER_SUPPLY_CHARGE_FULL=2139000
POWER_SUPPLY_MODEL_NAME=MS-1058
POWER_SUPPLY_MANUFACTURER=MSI Corp.
POWER_SUPPLY_SERIAL_NUMBER=
Comment 59 Mihail Kasadjikov 2011-01-18 12:05:05 UTC
Created attachment 44032 [details]
dmesg for 2.6.37 at MSI S271
Comment 60 Mihail Kasadjikov 2011-01-18 12:06:03 UTC
Created attachment 44042 [details]
dmidecode for 2.6.37 at MSI S271
Comment 61 Mihail Kasadjikov 2011-01-18 12:07:06 UTC
Created attachment 44052 [details]
kern.log for 2.6.37 at MSI S271
Comment 62 Lhacky 2011-02-07 01:37:40 UTC
Hi, I have discovered this problem as well on my Macbook Pro running Debian Squeeze -- the battery is new, non-apple, but Mac Os deals with it just fine.

Some info:
$ cat /sys/class/power_supply/BAT0/uevent 
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=12498000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_POWER_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=56000000
POWER_SUPPLY_ENERGY_FULL=52020000
POWER_SUPPLY_ENERGY_NOW=52000000
POWER_SUPPLY_MODEL_NAME=ASMB012
POWER_SUPPLY_MANUFACTURER=Sony012
POWER_SUPPLY_SERIAL_NUMBER=

$ uname -r
2.6.32-bpo.5-686
 (same problem on 2.6.32-5.686, the mainstream Debian squeeze kernel -- probably exactly the same kernel anyways)

I have charted the contents of /sys/class/power_supply/BAT0/{energy_now,power_now,current_now,voltage_now} over time; energy oscillates between 5200000 and 0, voltage between 12000000 and 0 (surely 3 orders of magnitude wrong?), whereas current and power are steadily registering 0

please let me know if you'd like any log attachments, etc. Would love some help.
Comment 63 Zhang Rui 2011-03-24 02:43:26 UTC
could you please verify if the patch at https://bugzilla.kernel.org/show_bug.cgi?id=24002#c12 helps?
Comment 64 Zhang Rui 2011-03-24 02:44:02 UTC
sorry, I mean the patch at https://bugzilla.kernel.org/show_bug.cgi?id=24002#c10
Comment 65 Zhang Rui 2011-04-01 06:43:40 UTC
ping...
Comment 66 Zhang Rui 2011-04-19 07:51:51 UTC
bug closed as there is no response from the bug reporter.
please re-open it if the problem still exists in the latest upstream kernel.
Comment 67 Lhacky 2011-06-08 03:13:59 UTC
Eeep, sorry to drop off the radar.  Problem still exists in debian kernel 2.6.38

$uname -rv
2.6.38-2-686 #1 SMP Sun May 8 14:49:45 UTC 2011

--I'm aware that I'm reporting on a Debian kernel in the Ubuntu bugzilla -- do you still want info/patch try-outs?
Comment 68 Lhacky 2011-06-08 05:51:58 UTC
oops.  Too many bugs to report, forgot where I was

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