Bug 24002

Created attachment 38522 [details]
kernel dot.config file

/proc/acpi/battery was deleted from 2.6.36, so that is expected.

This information was moved to /sys/class/power_supply
a number of releases past, do you see it there?

But even if yes, it is a problem if you see these warnings
in dmesg, did you see them in previous releases, or is
this a regression?

(In reply to comment #2)
> /proc/acpi/battery was deleted from 2.6.36, so that is expected.
> 
> This information was moved to /sys/class/power_supply
> a number of releases past, do you see it there?
> 
> But even if yes, it is a problem if you see these warnings
> in dmesg, did you see them in previous releases, or is
> this a regression?

/sys/class/power_supply/battery does not exist
/sys/class/power_supply/ADP1 is a link to a directory below /sys/devices

In /sys/class/power_supply/ADP1/power, values in various files change when the power cord is plugged and unplugged.  So the kernel is detecting something.  For what it is worth, gnome correctly determines the power supply but not the battery status.

I have not succeeded in building/running a pre-.34 kernel because opensuse includes so much that is incompatible with older kernels.  From the logs, though, I see the AE_BAD_PARAMETER error first appeared on 20100806, at which time I was running the 2.6.34 kernel.  That date coincides with upgrading from opensuse-11.2 to opensuse-11.3 and so who knows what changed in addition to the kernel.

I booted from a LiveCD with the 2.6.31 kernel.  Battery statistics were correct and no AE_BAD_PARAMETER errors.  So it appears that the error was introduced between 2.6.31 and 2.6.34.  Also, the bios is the latest:  AMI 1.11.

please attach the dmidecode of your laptop.

Created attachment 40342 [details]
Output from dmidecode

this smells like an EC bug, re-assign to ACPI-EC category.

please attach the acpidump output if you can still reproduce the bug in the latest upstream kernel.

Created attachment 51522 [details]
Output from acpidump

Kernel is 2.6.36-18-desktop

Created attachment 51672 [details]
patch: enable MSI workaround for more MSI laptops

could you please verify if the problem still exists in the latest upstream kernel please?
If yes, please apply the patch attached and see if it helps.

Created attachment 51822 [details]
boot.msg

The kernel messages remain after patching.

A message in boot.msg suggested unsetting CONFIG_ACPI_PROCFS, and so I did.  Now there is no indication of a battery and no kernel messages about it.  This seems like a clue based on Comment #2 in this bug report:
-- /sys/class/power_supply is empty
-- enabling /proc/acpi results in kernel messages.  But /proc/acpi should not be used, if I understand comment #2
-- with CONFIG_ACPI_PROCFS set, BAT1, not BAT0, is detected.  

Current boot.msg (attached) says "ACPI: EC: Detected MSI hardware, enabling workarounds."

please set CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROCFS_POWER.
and then check if you can get any data from /proc/acpi/battery/info and proc/acpi/battery/state.

And please check if you can still get the ACPI Exception and ACPI Error messages after applying the patch.

with the patch and CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROCFS_POWER set:

/proc/acpi/battery/BAT1/alarm 
/proc/acpi/battery/BAT1/info
/proc/acpi/battery/BAT1/state

exist but report "IO error, no such device" when I try to read them.  AE_BAD_PARAMETER errors are being logged multiple times per second.

Mar 24 11:39:37 pacific kernel: [ 1202.039813] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SB\
RG.EC__.BAT1._BST] (Node ffff880117efe2e0), AE_BAD_PARAMETER (20110112/psparse-536)
Mar 24 11:39:37 pacific kernel: [ 1202.039821] ACPI Exception: AE_BAD_PARAMETER, Evaluating _BST (20110\
112/battery-453)

what do you get if you run "cat /proc/acpi/battery/BAT1/info" only?
please attach the full dmesg output after running this command.

cat: /proc/acpi/battery/BAT1/info: No such device

This causes the following in dmesg:

Mar 25 10:01:29 pacific kernel: [81714.021567] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20110112/evregion-474)
Mar 25 10:01:29 pacific kernel: [81714.021574] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.UPBS] (Node ffff880117efe240), AE_BAD_PARAMETER (20110112/psparse-536)
Mar 25 10:01:29 pacific kernel: [81714.021583] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._BST] (Node ffff880117efe2e0), AE_BAD_PARAMETER (20110112/psparse-536)
Mar 25 10:01:29 pacific kernel: [81714.021591] ACPI Exception: AE_BAD_PARAMETER, Evaluating _BST (20110112/battery-453)

please set CONFIG_ACPI_DEBUG=y, uncomment the "/* #define DEBUG */" line in drivers/acpi/ec.c and rebuild the kernel.
then run the following commands:
1. echo 0xffffffff > /sys/modules/acpi/parameters/trace_debug_layer
2. echo 0xffffffff > /sys/modules/acpi/parameters/trace_debug_level
3. echo UPBS > /sys/modules/acpi/parameters/trace_method_name
4. echo 1 > /sys/modules/acpi/parameters/trace_debug_layer
5. cat /proc/acpi/battery/BAT1/info
6. attach the dmesg output

%% commands
echo 0xffffffff > /sys/modules/acpi/parameters/trace_debug_layer
echo 0xffffffff > /sys/modules/acpi/parameters/trace_debug_level
echo UPBS > /sys/modules/acpi/parameters/trace_method_name
echo 1 > /sys/modules/acpi/parameters/trace_debug_layer
cat /proc/acpi/battery/BAT1/info

%% stdout/stderr
pacific /var/log# /sys/modules/acpi/parameters/trace_debug_layer: No such file or directory.
pacific /var/log# /sys/modules/acpi/parameters/trace_debug_level: No such file or directory.
pacific /var/log# /sys/modules/acpi/parameters/trace_method_name: No such file or directory.
pacific /var/log# /sys/modules/acpi/parameters/trace_debug_layer: No such file or directory.
pacific /var/log# cat: /proc/acpi/battery/BAT1/info: No such device

%% dmesg
Apr  4 16:41:06 pacific kernel: [ 2143.972765] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.972768] ACPI: EC: transaction start
Apr  4 16:41:06 pacific kernel: [ 2143.973322] ACPI: EC: <--- command = 0x80
Apr  4 16:41:06 pacific kernel: [ 2143.973449] ACPI: EC: ~~~> interrupt
Apr  4 16:41:06 pacific kernel: [ 2143.973452] ACPI: EC: ---> status = 0x08
Apr  4 16:41:06 pacific kernel: [ 2143.973454] ACPI: EC: <--- data = 0x31
Apr  4 16:41:06 pacific kernel: [ 2143.973512] ACPI: EC: ~~~> interrupt
Apr  4 16:41:06 pacific kernel: [ 2143.973516] ACPI: EC: ---> status = 0x03
Apr  4 16:41:06 pacific kernel: [ 2143.973519] ACPI: EC: ---> data = 0x09
Apr  4 16:41:06 pacific kernel: [ 2143.973522] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973526] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973581] ACPI: EC: ~~~> interrupt
Apr  4 16:41:06 pacific kernel: [ 2143.973585] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973588] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973592] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973877] ACPI: EC: ---> status = 0x00
Apr  4 16:41:06 pacific kernel: [ 2143.973879] ACPI: EC: transaction end
Apr  4 16:41:06 pacific kernel: [ 2143.973933] ACPI Exception: AE_BAD_PARAMETER, Returne\
d by Handler for [EmbeddedControl] (20110112/evregion-474)
Apr  4 16:41:06 pacific kernel: [ 2143.973938] ACPI Error: Method parse/execution failed\
 [\_SB_.PCI0.SBRG.EC__.BAT1.UPBI] (Node ffff880117efe268), AE_BAD_PARAMETER (20110112/ps\
parse-536)
Apr  4 16:41:06 pacific kernel: [ 2143.973947] ACPI Error: Method parse/execution failed\
 [\_SB_.PCI0.SBRG.EC__.BAT1._BIF] (Node ffff880117efe308), AE_BAD_PARAMETER (20110112/ps\
parse-536)
Apr  4 16:41:06 pacific kernel: [ 2143.973955] ACPI Exception: AE_BAD_PARAMETER, Evaluat\
ing _BIF (20110112/battery-417)

oops, it should be /sys/module/....

%% commands
echo 0xffffffff > /sys/module/acpi/parameters/trace_debug_layer
echo 0xffffffff > /sys/module/acpi/parameters/trace_debug_level
echo UPBS > /sys/module/acpi/parameters/trace_method_name
echo 1 > /sys/module/acpi/parameters/trace_debug_layer
cat /proc/acpi/battery/BAT1/info

%% stderr/stdout
cat: /proc/acpi/battery/BAT1/info: No such device

%% dmesg output
Apr  6 12:26:15 pacific kernel: [159652.697049] ACPI: EC: ---> status = 0x00
Apr  6 12:26:15 pacific kernel: [159652.697052] ACPI: EC: transaction start
Apr  6 12:26:15 pacific kernel: [159652.697604] ACPI: EC: <--- command = 0x80
Apr  6 12:26:15 pacific kernel: [159652.697717] ACPI: EC: ~~~> interrupt
Apr  6 12:26:15 pacific kernel: [159652.697720] ACPI: EC: ---> status = 0x08
Apr  6 12:26:15 pacific kernel: [159652.697722] ACPI: EC: <--- data = 0x31
Apr  6 12:26:15 pacific kernel: [159652.697779] ACPI: EC: ~~~> interrupt
Apr  6 12:26:15 pacific kernel: [159652.697783] ACPI: EC: ---> status = 0x02
Apr  6 12:26:15 pacific kernel: [159652.697838] ACPI: EC: ~~~> interrupt
Apr  6 12:26:15 pacific kernel: [159652.697842] ACPI: EC: ---> status = 0x01
Apr  6 12:26:15 pacific kernel: [159652.697845] ACPI: EC: ---> data = 0x09
Apr  6 12:26:15 pacific kernel: [159652.697849] ACPI: EC: ---> status = 0x00
Apr  6 12:26:15 pacific kernel: [159652.697852] ACPI: EC: ---> status = 0x00
Apr  6 12:26:15 pacific kernel: [159652.698162] ACPI: EC: ---> status = 0x00
Apr  6 12:26:15 pacific kernel: [159652.698163] ACPI: EC: transaction end
Apr  6 12:26:15 pacific kernel: [159652.698217] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler \
for [EmbeddedControl] (20110112/evregion-474)
Apr  6 12:26:15 pacific kernel: [159652.698222] ACPI Error: Method parse/execution failed [\_SB_.PCI0.\
SBRG.EC__.BAT1.UPBI] (Node ffff880117efe268), AE_BAD_PARAMETER (20110112/psparse-536)
Apr  6 12:26:15 pacific kernel: [159652.698231] ACPI Error: Method parse/execution failed [\_SB_.PCI0.\
SBRG.EC__.BAT1._BIF] (Node ffff880117efe308), AE_BAD_PARAMETER (20110112/psparse-536)
Apr  6 12:26:15 pacific kernel: [159652.698239] ACPI Exception: AE_BAD_PARAMETER, Evaluating _BIF (201\
10112/battery-417)

please run "cat /proc/acpi/battery/BAT1/state" instead this time and I guess there will be a lot of messages in the dmesg output.

Created attachment 53772 [details]
dmesg after "cat /proc/acpi/battery/BAT1/state"

weird, I still didn't get any useful debug output.
would you please run
1. echo 0xffffffff > /sys/module/acpi/parameters/debug_layer
2. echo 0xffffffff > /sys/module/acpi/parameters/debug_layer
3. cat /proc/acpi/battery/BAT1/state
and then attach the dmesg output?

Created attachment 54272 [details]
dmesg

I guessed that you meant to set the debug_level with the second echo, not set the debug_layer twice.  I hope this was ok--it produced quite the pile of kernel messages.

Created attachment 54342 [details]
ec debug patch

please apply this patch, and attach the dmesg output after redoing the test.

Created attachment 54382 [details]
dmesg

I upgraded to OpenSuse-11.4.  The installer booted a stripped down version of the 2.6.37 kernel.  With this kernel, I get what appears to be correct data from /proc/acpi/battery/BAT1/info and state.  This suggests that the ec and battery modules are fine but that something else in the kernel is preventing access to the battery device.

Unfortunately I don't know how to strip down the standard kernel to produce the kernel opensuse uses for installs.  I'll see if I can get that.

A solution is to disable ACPI_WMI in the kernel config.  This makes the battery status available and stops the error messages to dmesg.  If you want to test a patch that disables WMI if it is broken then I'm happy to do so.  Otherwise, thanks for your help.

Matthew,
have you ever seen such kind of problems that acpi wmi driver breaks ACPI EC?

Nope. The WMI code should do very little unless one of the hardware-specific WMI drivers loads. Is that happening here?

The motherboard provides a hotkey that Vista uses to cycle between 5 power management modes.  The comments in msi-wmi.c say the module handles the hotkeys, but not this one.  I have no idea about any of this, but it seems a reasonable place to start looking for the problem.  Also, a linux forum posting has unearthed another user with this motherboard and the same problem.

I can verify that excluding MSI in the kernel configuration allows the battery information to be seen.  I see no hardware-specific WMI modules loaded when WMI is built-in.

Would it be possible to add a kernel boot parameter similar to acpi=off to allow a user to turn off WMI on flaky hardware with out compiling the entire kernel?  For this particular laptop motherboard, MS-171F, no functionality is missing without it.  All the buttons work, even the hot key mentioned in comment #30 (labeled P1) generates the character "±" on the command line and in other applications.

It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?

Problem still exists with 3.1.0

Created attachment 98781 [details]
patch

Please try this patch.

ping ...

I no longer have motherboard.  Suggest pinging fellow who provided comment #31.

Ok. Thanks for reply.

Hi Jones:
        Could you test the patch in the comment #34?

Anyone can test the patch in the Comment #34 ? From my opinions, this problem is caused by wmi driver's EC operation region handler doesn't support read/write operation of longer than 8 bit data and return bad param error.

 Device (SCM0)
        {
          Name (_HID, "pnp0c14")
          Name (_UID, Zero)
          ...
          OperationRegion (EC, EmbeddedControl, Zero, 0x0100)
                            Field (EC, ByteAcc, NoLock, Preserve)
                            {
                                        Offset (0x2D),
                                T2D0,   1,
                                T2D1,   4,
                                T2D5,   3,
                                TD2E,   8,
                                TD2F,   8,
                                TD30,   8,
                                TD31,   8,
                                TD32,   8,
                                TD33,   8,
                                        Offset (0x35),
                                TD35,   8,
                                TD36,   8,
                                        Offset (0x38),
                                TD38,   16,
                                TD3A,   16,

Sorry for not replying earlier.  I no longer regularly check the email account I used to register an account here.

I cannot recall if the problem went away for me upon upgrading to Ubuntu 11.10 (based on kernel version 3.0.4) or 12.04 (based on kernel version 3.2.14), but I no longer need to recompile the kernel to have access to the battery information.  Since deBK still had the problem with kernel version 3.1, I suppose the problem went away with 12.04.  I am currently running 12.04.2, which is based on kernel version 3.5.7.2, and still have no problems.

Did you introduce a patch that was incorporated into the mainline kernel by version 3.2.14?

Hi Jones:
         Thanks for response. Please check whether the issue take place with CONFIG_ACPI_WMI in the v3.9. If it still existed, try my patch in the Comment #34.

Hi Jones:
         Any update?

Since no response, close this bug as will_fix_later