Bug 24002

Summary: ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] - generic laptop with a MS-171F motherboard
Product: ACPI Reporter: deBK (debk)
Component: ECAssignee: Lan Tianyu (tianyu.lan)
Status: CLOSED WILL_FIX_LATER    
Severity: normal CC: acpi-bugzilla, alan, mjg59-kernel, rui.zhang, tianyu.lan, travisejones
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.1.0 Subsystem:
Regression: No Bisected commit-id:
Attachments: boot.msg
kernel dot.config file
Output from dmidecode
Output from acpidump
patch: enable MSI workaround for more MSI laptops
boot.msg
dmesg after "cat /proc/acpi/battery/BAT1/state"
dmesg
ec debug patch
dmesg
patch

Description deBK 2010-11-29 16:38:23 UTC
Created attachment 38512 [details]
boot.msg

Forgive me if this has been addressed.  I am not finding any current solutions to the problem.

On a generic laptop with a MS-171F motherboard, BAT1 is detected on boot:

<6>[ 7.147120] ACPI: Battery Slot [BAT1] (battery present)
<6>[ 7.161354] ACPI: AC Adapter [ADP1] (on-line)

but /proc/acpi/battery/info and proc/acpi/battery/state have no data:

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

ACPI logs the following to /var/log/messages every few minutes:

Nov 28 09:55:32 xxx kernel: [840329.315595] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (201007\
02/evregion-474)
Nov 28 09:55:32 xxx kernel: [840329.315605] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1\
.UPBI] (Node ffff88011bafc268), AE_BAD_PARAMETER
Nov 28 09:55:32 xxx kernel: [840329.315616] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1\
._BIF] (Node ffff88011bafc308), AE_BAD_PARAMETER
Nov 28 09:55:32 xxx kernel: [840329.315626] ACPI Exception: AE_BAD_PARAMETER, Evaluating _BIF (20100702/battery-404)

There is only one battery in the laptop and the kernel finds it as BAT1 not BAT0.  The battery works fine and, in the past, linux has correctly detected the status.  I have not been able to successfully build older kernels older than 2.6.34 with OpenSuse 11.3 (too hard to untangle whatever the distribution is doing), but I know that the problems existed with with OpenSuse 11.1 (2.6.27 kernel), went away with 11.2 (2.6.31 kernel), and are back with 11.3 (2.6.34 and later kernels). 

The battery works fine but obviously there is no graceful shut down when it runs down since there is no report of battery power in /proc/acpi
Comment 1 deBK 2010-11-29 16:39:02 UTC
Created attachment 38522 [details]
kernel dot.config file
Comment 2 Len Brown 2010-11-30 03:08:21 UTC
/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?
Comment 3 deBK 2010-11-30 15:39:54 UTC
(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.
Comment 4 deBK 2010-12-02 17:52:42 UTC
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.
Comment 5 Zhang Rui 2010-12-16 06:14:11 UTC
please attach the dmidecode of your laptop.
Comment 6 deBK 2010-12-16 12:29:05 UTC
Created attachment 40342 [details]
Output from dmidecode
Comment 7 Zhang Rui 2010-12-27 02:06:32 UTC
this smells like an EC bug, re-assign to ACPI-EC category.
Comment 8 Zhang Rui 2011-03-21 07:52:19 UTC
please attach the acpidump output if you can still reproduce the bug in the latest upstream kernel.
Comment 9 deBK 2011-03-21 14:30:48 UTC
Created attachment 51522 [details]
Output from acpidump

Kernel is 2.6.36-18-desktop
Comment 10 Zhang Rui 2011-03-23 02:32:29 UTC
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.
Comment 11 deBK 2011-03-23 21:58:46 UTC
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."
Comment 12 Zhang Rui 2011-03-24 00:55:16 UTC
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.
Comment 13 deBK 2011-03-24 15:40:49 UTC
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)
Comment 14 Zhang Rui 2011-03-25 03:23:14 UTC
what do you get if you run "cat /proc/acpi/battery/BAT1/info" only?
please attach the full dmesg output after running this command.
Comment 15 deBK 2011-03-25 20:53:45 UTC
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)
Comment 16 Zhang Rui 2011-04-01 06:41:43 UTC
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
Comment 17 deBK 2011-04-05 00:42:26 UTC
%% 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)
Comment 18 Zhang Rui 2011-04-06 01:59:10 UTC
oops, it should be /sys/module/....
Comment 19 deBK 2011-04-06 16:35:44 UTC
%% 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)
Comment 20 Zhang Rui 2011-04-07 01:46:43 UTC
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.
Comment 21 deBK 2011-04-07 15:09:46 UTC
Created attachment 53772 [details]
dmesg after "cat /proc/acpi/battery/BAT1/state"
Comment 22 Zhang Rui 2011-04-11 08:53:06 UTC
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?
Comment 23 deBK 2011-04-13 17:04:51 UTC
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.
Comment 24 Zhang Rui 2011-04-14 01:43:03 UTC
Created attachment 54342 [details]
ec debug patch

please apply this patch, and attach the dmesg output after redoing the test.
Comment 25 deBK 2011-04-14 19:50:57 UTC
Created attachment 54382 [details]
dmesg
Comment 26 deBK 2011-04-25 18:06:55 UTC
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.
Comment 27 deBK 2011-04-26 21:27:03 UTC
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.
Comment 28 Zhang Rui 2011-04-27 06:44:38 UTC
Matthew,
have you ever seen such kind of problems that acpi wmi driver breaks ACPI EC?
Comment 29 Matthew Garrett 2011-04-27 11:36:07 UTC
Nope. The WMI code should do very little unless one of the hardware-specific WMI drivers loads. Is that happening here?
Comment 30 deBK 2011-04-27 14:20:12 UTC
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.
Comment 31 Travis Jones 2011-06-22 05:41:08 UTC
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.
Comment 32 Zhang Rui 2012-01-18 02:26:26 UTC
It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?
Comment 33 deBK 2012-03-24 13:47:55 UTC
Problem still exists with 3.1.0
Comment 34 Lan Tianyu 2013-04-15 14:06:14 UTC
Created attachment 98781 [details]
patch

Please try this patch.
Comment 35 Lan Tianyu 2013-04-22 03:21:13 UTC
ping ...
Comment 36 deBK 2013-04-22 10:47:02 UTC
I no longer have motherboard.  Suggest pinging fellow who provided comment #31.
Comment 37 Lan Tianyu 2013-04-22 11:17:31 UTC
Ok. Thanks for reply.

Hi Jones:
        Could you test the patch in the comment #34?
Comment 38 Lan Tianyu 2013-05-05 13:08:43 UTC
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,
Comment 39 Travis Jones 2013-05-11 16:59:28 UTC
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?
Comment 40 Lan Tianyu 2013-05-13 00:55:27 UTC
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.
Comment 41 Lan Tianyu 2013-05-20 01:04:42 UTC
Hi Jones:
         Any update?
Comment 42 Lan Tianyu 2013-06-03 07:03:47 UTC
Since no response, close this bug as will_fix_later