Bug 14446
| Summary: | battery status info broken/useless in 2.6.32-rc3 - MSI PR200 (possibly others, too) | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Eddy Petrișor (eddy.petrisor+linbug) |
| Component: | EC | Assignee: | Zhang Rui (rui.zhang) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | high | CC: | astarikovskiy, florian, hamer.mk, lenb, rjw, rui.zhang, terrorpine, tswatzke, uh.linux |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32-rc3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 13615 | ||
| Attachments: |
debug patch
syslog of 2.6.32-rc3 with debug patch dmidecode output debug patch #2 syslog of 2.6.32-rc3 with first detection patch syslog of 2.6.32-rc3 + detection patch fix MSI detection fix MSI detection syslog with some ACPI debug dmidecode output for MSI S271 dmesg for MSI S271 dmesg for 2.6.37 at MSI S271 dmidecode for 2.6.37 at MSI S271 kern.log for 2.6.37 at MSI S271 |
||
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. Eddy, Could you please attach dmesg? what happens if you do cat of /proc/acpi/battery/*/*? (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 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 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.
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.
Do you have dmidecode output handy? Please attach it here. 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.
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.
Created attachment 23493 [details]
debug patch #2
Eddy, please check if this patch makes your MSI detected.
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 :-) .
I meant "... identify the commit introducing the regression ..." Eddy, it seems you still use old patch. In new patch "#define DEBUG" is left commented out. (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 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
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? 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 Created attachment 23532 [details]
fix MSI detection
Eddy, I think, I've found a problem with detection of MSI hardware, please check.
(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... Created attachment 23541 [details]
fix MSI detection
yes, my fault... please try this one instead...
(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. 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
I think this is regression from this patch 56f382a08722186623400180adbb9d1be1721cee. (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 for your remaining issue, please try to revert patch mentioned in #23 and do 'grep . /proc/acpi/battery/*/*' beforehand (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 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 (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. presence of /proc files is controlled by config variable CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROCFS_POWER (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 *** Bug 14764 has been marked as a duplicate of this bug. *** Alexey, is there a patch proposed for upstream here? Lastest 2.6.32.1 ships without patch...After patching battery status works great. Len, patch in comment #20 should go up. 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. shipped in linux-2.6.33-rc2 and sent to .32.stable closed. *** Bug 14740 has been marked as a duplicate of this bug. *** 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. oh i hate the DMI maintenance game. Tom, did you put MICRO-STAR as DMI_BIOS_VENDOR, or as DMI_SYS_VENDOR? Tom, probably best to just attach the output from dmidecode 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
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.
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. Created attachment 25365 [details]
dmidecode output for MSI S271
Created attachment 25367 [details]
dmesg for MSI S271
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 - ... does the problem still exist in the latest upstream kernel? say 2.6.35 or 2.6.36-rc? 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). (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. (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. 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. 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 Please reopen the bug. Mihail, can you please verify if the problem you met is a duplicate of bug #14461? oh.sorry, I just saw your post. Mihail Please test 2.6.37 and attach the complete dmesg. Also please attach the complete output from dmidecode for your MSI S271. 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= Created attachment 44032 [details]
dmesg for 2.6.37 at MSI S271
Created attachment 44042 [details]
dmidecode for 2.6.37 at MSI S271
Created attachment 44052 [details]
kern.log for 2.6.37 at MSI S271
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.
could you please verify if the patch at https://bugzilla.kernel.org/show_bug.cgi?id=24002#c12 helps? sorry, I mean the patch at https://bugzilla.kernel.org/show_bug.cgi?id=24002#c10 ping... 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. 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? oops. Too many bugs to report, forgot where I was |
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.