2.6.32 is very very old - is this still seen with a modern kernel, and does this cause any problems beyond the warnings ?

No, it does not cause any problems, as far as i know.

i was able to trace it, and if blacklist power_meter module it went away.

Definetly, this Error message is generated by power_meter module.

Let me leave it open for a bit so we can figure out if the warning shouldn't be seen in the first place.

No, it does not cause any problems, as far as i know.

i was able to trace it, and if blacklist power_meter module it went away.

Definetly, this Error message is generated by power_meter module.

Still seeing this with 3.3.8, for what that's worth.

Hello,

Please attach your acpidump:
# acpidump > acpi_tables.out

Thanks.

can't really test a newer kernel on this hardware right now.

3.3.8-1.fc16.x86_64 logs:

[    7.355933] ACPI Error: No handler for Region [SYSI] (ffff881fd34f71b0) [IPMI] (20120111/evregion-376)
[    7.355938] ACPI Error: Region IPMI (ID=7) has no handler (20120111/exfldio-306)
[    7.355943] ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node ffff881fd34f6dc0), AE_NOT_EXIST (20120111/psparse-536)
[    7.355950] ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node ffff881fd34f6d20), AE_NOT_EXIST (20120111/psparse-536)
[    7.355957] ACPI Exception: AE_NOT_EXIST, Evaluating _PMC (20120111/power_meter-773)

will attach acpidump now.

Created attachment 94211 [details]
acpi tables from Dell blade

Thanks ALbert.

Hi Lv,
Can you please take a look at this? Thanks.

Thanks Albert.

OK, I'll take a look at this bug.

Created attachment 94221 [details]
Add IPMI dependency for ACPI power meter module

Looks like this could be a solution as the ACPI power meter device node shown below:

        Device (PMI0)
        {
            Name (_HID, "ACPI000D")  // _HID: Hardware ID
                         ^^^^^^^^
            Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
            Name (_UID, "PMI")  // _UID: Unique ID
            Name (_STA, 0x0F)  // _STA: Status
            OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
                                   ^^^^
            Field (SYSI, BufferAcc, Lock, Preserve)
            {
                AccessAs (BufferAcc, 0x01), 
                Offset (0x58), 
                SCMD,   8, 
                GCMD,   8
            }

Not sure if this is the best way. IMO, "select ACPI_IPMI" is better but currently ACPI_IPMI depends on EXPERIMENTAL.

Hi, Mark

Could you give this patch a try?
https://bugzilla.kernel.org/attachment.cgi?id=94221

Thanks.

Hi Mark and Albert,

Care to give the patch mentioned in comment #11 a test? Thanks.

I'll try to test by early next week. Getting a custom built kernel onto the relevant hardware is a bit tricky, but I'll see what I can do.

Sorry.
The patch has typo issue. IMPI should be IPMI.
We are discussing internally on ACPI address space handler issues.
There might be better approaches for this bug.

Hi,

Sorry for the delayed response.
I was working on other things and now I'm back.

I can see two issues in this bug (please refer to a minimized DSDT uploaded in a later reply):

1. IPMI space handler shouldn't be installed on a device basis.  In this case, the IPMI OperationRegion is defined out of the KCS system interface scope, which will cause "missing handler" problem.
2. There are no relationship between the acpi power meter module and the acpi_ipmi module, there's nothing can trigger a module load for the acpi_ipmi module.

I've fixed the issue 1, and the patch will be uploaded in a later reply.

Could you give me a test.  I don't have any server platform available now for testing.

If you still have problem w/ issue2 during the test, please do not configure ACPI_IPMI as module or manually load it before accessing acpi power meter features.

Thanks in advance.

Created attachment 103611 [details]
The minimized DSDT for reference

The minimized DSDT.
We can see that the ACPI power meter device (ACPI000D) is located out of the scope of the IPMI system interface device (IPI0001) whose _IFT returns a type KCS (0x01).

Created attachment 103621 [details]
[INTERNAL RFC PATCH v1.0] ACPI/IPMI: Fix IPMI operation

The is the patch to fix the address space handler registration problem.
And the ipmi_device access should thus be redesigned to live with bmc_registeration/unregisteration cases.
Please check if it works for you.

Unfortunately I don't have the infrastructure ready to test custom kernels on this hardware. Any chance that this request can be sent to lkml? Somebody there probably has a Dell ready to test?

There is a process issue that prevent me from doing so.
I can help to back port the codes to an earlier kernel revision.
Which Linux kernel revision do you prefer to use?

And could you also upload the DMI information for the machine?

Thanks in advance

I fixed some issues that can be found in acpi_ipmi along with fixes for the above mentioned 2 problems.
The patchset is also back ported to the v3.2 kernel.
I'm still seeking platforms for validation.
Can anybody here help me to test the patches?
I will report the test result here if I can do this myself.

Thanks in advance.

Created attachment 105141 [details]
[PATCH for v3.2] ACPI/IPMI: Fix several issues in the current codes

Patches for v3.2 tagged kernels.

Created attachment 105151 [details]
[PATCH for v3.10-rc2] ACPI/IPMI: Fix several issues in the current codes

Patches for v3.10-rc2 tagged kernels.

Created attachment 106561 [details]
DBG PATCH - ACPI IPMI issue fixes

Hi,

This patch set is tested for a fake device accessing IPMI operation regions on an IPMI capable system.
The fake device is created using customized DSDT.

It would be better to test the patches for a real device.
I wonder if there's anyone still working on this can help to confirm whether this bug has been fixed by the patches.

Patchset has been sent to the kernel mailing list.

The patch 5 is the fix patch for this bug:
https://patchwork.kernel.org/patch/2831826/
[05/13] ACPI/IPMI: Fix issue caused by the per-device registration of the IPMI operation region handler

Please find the others in the same thread.

Hi Lv Zheng

I think I'm facing the same problem (as Albert Strasheim) -- Only some numbers are different:

ACPI Error: No handler for Region [SYSI] (ffff8810790cb540) [IPMI] (20130328/evregion-161)
ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node ffff8830794b4740), AE_NOT_EXIST (20130328/psparse-537)
ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node ffff8830794b4718), AE_NOT_EXIST (20130328/psparse-537)
ACPI Exception: AE_NOT_EXIST, Evaluating _PMC (20130328/power_meter-753)

$ uname -a
Linux dell1 3.10-0.bpo.3-amd64 #1 SMP Debian 3.10.11-1~bpo70+1 (2013-09-24) x86_64 GNU/Linux

I tried your patches in attachment 106561 [details] (applied one by one from 2 to 10, all succeeded, only lv_ipmi10.patch has some offset lines), but see no difference at all (error still occur).

I build the kernel just like building other debian backports, I don't know whether this is a correct way. But at least `uname` changed, and in kern.log the number of 'Freeing unused kernel memory:' also changed.

The patchset has been refined and is shipped in linux-pm/linux-next branch now:
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?qt=author&q=Lv+Zheng&h=linux-next

2013-09-30 ACPI / IPMI: Cleanup coding styles Lv Zheng 1 -40/+65 
2013-09-30 ACPI / IPMI: Cleanup some Kconfig codes Lv Zheng 1 -1/+2 
2013-09-30 ACPI / IPMI: Cleanup some inclusion codes Lv Zheng 1 -14/+1 
2013-09-30 ACPI / IPMI: Cleanup some initialization codes Lv Zheng 1 -4/+3 
2013-09-30 ACPI / IPMI: Cleanup several acpi_ipmi_device members Lv Zheng 1 -17/+13 
2013-09-30 ACPI / IPMI: Add reference counting for ACPI IPMI transfers Lv Zheng 1 -32/+85 
2013-09-30 ACPI / IPMI: Use global IPMI operation region handler Lv Zheng 1 -47/+34 
2013-09-30 ACPI / IPMI: Fix race caused by the unprotected ACPI IPMI user Lv Zheng 1 -93/+156 
2013-09-30 ACPI / IPMI: Fix race caused by the timed out ACPI IPMI transfers Lv Zheng 1 -22/+27 
2013-09-30 ACPI / IPMI: Fix race caused by the unprotected ACPI IPMI transfers Lv Zheng 1 -2/+6 
2013-09-30 ACPI / IPMI: Fix potential response buffer overflow Lv Zheng 1 -20/+33 
2013-09-25 ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler() Lv Zheng 1 -10/+14 

What you need to do is waiting for one cycle before trying the next release of Linus tree.

If you (In reply to eddy from comment #27)
> Hi Lv Zheng

$ uname -a
Linux dell1 3.10-0.bpo.3-amd64 #1 SMP
> Debian 3.10.11-1~bpo70+1 (2013-09-24) x86_64 GNU/Linux

> I tried your patches
> in attachment 106561 [details] (applied one by one from 2 to 10, all
> succeeded, only lv_ipmi10.patch has some offset lines), but see no
> difference at all (error still occur).

Could you upload the acpidump/dmesg to let me check what's the issue for your machine?

I build the kernel just like
> building other debian backports, I don't know whether this is a correct way.
> But at least `uname` changed, and in kern.log the number of 'Freeing unused
> kernel memory:' also changed.

If you want to do a back port for other stable trees, you may need to cherry pick all of the patches listed above from the linux-next branch of the linux-pm tree.

You may need to check lsmod output to see if ipmi_si and acpi_ipmi are all there listed.

acpi_ipmi is not an automatcally loaded module, if so, you need to do "modprobe acpi_ipmi".
I have one patch to make it's possible to trigger acpi_ipmi loading from ipmi_si, but this patch is not upstreamed.

Created attachment 112511 [details]
acpi tables from Dell PowerEdge R820

Created attachment 112521 [details]
dmesg - kernel that applied attachment 106561 [details] - Dell R820

the kernel parameters there
"rootdelay=1" (Another bug?) make sure LVM usable, otherwise the system won't boot.
"intremap=no_x2apic_optout" otherwise kernel will tell me "Your BIOS is broken and requested that x2apic be disabled."
"intel_pstate=disable" I want to try the cpufrequtils.
The ACPI Error wil be there both with or without last two options.

No much difference before applying attachment 106561 [details], only detected CPU frequency and memory usage are silghtly different.

(In reply to Lv Zheng from comment #30)
> You may need to check lsmod output to see if ipmi_si and acpi_ipmi are all
> there listed.
> 
> acpi_ipmi is not an automatcally loaded module, if so, you need to do
> "modprobe acpi_ipmi".
> I have one patch to make it's possible to trigger acpi_ipmi loading from
> ipmi_si, but this patch is not upstreamed.

"lsmod | grep ipmi"   show me nothing.
"modprobe acpi_ipmi"  load the module(show nothing), and return 0.


(from comment #29)
> If you want to do a back port for other stable trees, you may need to cherry 
> pick all of the patches listed above from the linux-next branch of the
> linux-pm tree.

sounds a bit complex... I may try it after you analyse my attachments, and tell me some good news :-)

(In reply to eddy from comment #33)
> (In reply to Lv Zheng from comment #30)
> You may need to check lsmod output
> to see if ipmi_si and acpi_ipmi are all
> there listed.
> 
> acpi_ipmi is
> not an automatcally loaded module, if so, you need to do
> "modprobe
> acpi_ipmi".
> I have one patch to make it's possible to trigger acpi_ipmi
> loading from
> ipmi_si, but this patch is not upstreamed.

"lsmod | grep
> ipmi"   show me nothing.
This means you didn't load the ipmi_si and acpi_ipmi module.

"modprobe acpi_ipmi"  load the module(show
> nothing), and return 0.

OK, please try to do a "make menuconfig" before building a customized kernel, modifying ACPI_IPMI and IPMI_SI from "M" to "Y".
The fix for the "module loading" triggering issue is not a part of the upstreamed IPMI fixes now.

(from comment #29)
> If you want to do a back port
> for other stable trees, you may need to cherry 
> pick all of the patches
> listed above from the linux-next branch of the
> linux-pm tree.

sounds a
> bit complex... I may try it after you analyse my attachments, and tell me
> some good news :-)

Yes, there might be other issues related to ipmi_si driver matching on your machine.  If so, you probably need to open a new bug.
Let me check the acpidump and report back later.

I checked the acpidump and found this:
    Scope (\_SB)
    {
        Device (PMI0)
        {
            Name (_HID, "ACPI000D")  // _HID: Hardware ID

This device is reporting the errors.  It is a ACPI power meter device as its pnpid is ACPI000D.
It's under \_SB, so all the fixes posted here should be required.

            Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
            Name (_UID, "PMI")  // _UID: Unique ID
            Name (_STA, 0x0F)  // _STA: Status
            OperationRegion (SYSI, IPMI, 0x0600, 0x0100)
            Field (SYSI, BufferAcc, Lock, Preserve)
            {
                AccessAs (BufferAcc, 0x01), 
                Offset (0x58), 
                SCMD,   8, 
                GCMD,   8
            }

            OperationRegion (POWR, IPMI, 0x3000, 0x0100)
            Field (POWR, BufferAcc, Lock, Preserve)
            {
                AccessAs (BufferAcc, 0x01), 
                Offset (0xB3), 
                GPMM,   8
            }

            ...
            Method (_PMC, 0, NotSerialized)  // _PMC: Power Meter Capabilities
            {
                ...
            }

            Method (_GHL, 0, NotSerialized)  // _GHL: Get Hardware Limit
            {
                ...
            }
Errors are generated by Linux when these 2 control methods are executed.

...
                Device (NIPM)
                {
                    Name (_HID, EisaId ("IPI0001"))  // _HID: Hardware ID

This device will be driven by ipmi_si module as its pnpid is IPI0001.

                    Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
                    Name (_UID, 0x05)  // _UID: Unique ID
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (LEqual (TOOS, 0x01))
                        {
                            Return (0x0F)

                        }
                        Else
                        {
                            If (LOr (LEqual (TOOS, 0x07), LEqual (TOOS, 0x08)))
                            {
                                Return (0x0F)
                            }
                            Else
                            {
                                Return (0x00)
                            }
                        }
                    }
The device will only exist when TOOS equals 0x01 or 0x07 or 0x08.
Perhaps you need to find a way in your BIOS configuration to enable this device to be used by OS.  See _OSI below.

        Name (TOOS, 0x00)
        Method (INIC, 0, NotSerialized)
        {
            If (CondRefOf (_OSI, Local0))
            {
                If (\_OSI ("Windows 2001"))
                {
                    Store (0x05, TOOS)
                }

                If (\_OSI ("Windows 2001.1"))
                {
                    Store (0x06, TOOS)
                }

                If (\_OSI ("Windows 2001.1 SP1"))
                {
                    Store (0x07, TOOS)
                }

                If (\_OSI ("Windows 2006"))
                {
                    Store (0x08, TOOS)
                }

                If (\_OSI ("Windows 2006.1"))
                {
                    Store (0x08, TOOS)
                }

                If (\_OSI ("Linux"))
                {
                    Store (0x01, TOOS)
                }
It seems you need to feed "acpi_osi=! acpi_osi=Linux" boot parameters to make the IPI0001 device matched by the Linux kernel.  You can also use "Windows 2006", "Windows 2001.1 SP1", "Windows 2006.1" instead of "Linux" here, 

Unfortunately, I'm not sure if the commit to implement "acpi_osi=!" is in your tree.  This option is implemented by my following commit:
Commit: 5dc17986fdc3d2425838cb8d699152c3c30d1208
From: Lv Zheng <lv.zheng@intel.com> 2013-07-22 08:08:25 (GMT) 
Subject ACPI: Add facility to disable all _OSI OS vendor strings
It's already in the upstream kernel.
                }

Your machine is also sufferring from the 2 issues listed in comment 16.

The problem you are reporting relates to the issue 2.
Which is no longer included by the fix series for some reasons.

For now, my suggestion is:
1. find the _OSI commit, apply it
2. apply the patches in this thread
3. do a "make menuconfig" before building a customized kernel, modifying ACPI_IPMI and IPMI_SI from "M" to "Y".
4. add boot paraemters "acpi_osi=xx" as listed above

I checked the code, sadly, your commit
Commit: 5dc17986fdc3d2425838cb8d699152c3c30d1208
is not there (uname -v = "Debian 3.10.11-1~bpo70+1 (2013-09-24)").

You remind me that there is a BIOS setting, which let you choose CPU power management control by hardware or OS. Seems the default setting is "control by hardware"... So I will check that first tomorrow.

If after I tune the BIOS settings, the errors are gone, do you still need me to test your patches?

(In reply to eddy from comment #36)
> I checked the code, sadly, your commit
Commit:
> 5dc17986fdc3d2425838cb8d699152c3c30d1208
is not there (uname -v = "Debian
> 3.10.11-1~bpo70+1 (2013-09-24)").

You remind me that there is a BIOS
> setting, which let you choose CPU power management control by hardware or
> OS. Seems the default setting is "control by hardware"... So I will check
> that first tomorrow.

It seems only \_OSI can make TOOS to be 0x01,0x07,0x08.  The BIOS setting might not work.

If after I tune the BIOS settings, the errors are
> gone, do you still need me to test your patches?

If you can find the IPMI system management interface (SMI) device on your system, you needn't checkout the OSI commit.

(In reply to eddy from comment #36)
If after I tune the BIOS settings, the errors are
> gone, do you still need me to test your patches?

Tests are always welcome. :-)
I'll collect all of the patches required and post them here.

Created attachment 112601 [details]
Linux-PM upstreamed patches + 2 additional patches

The zip file contains:
1. 2 patches in <kernel/git/torvalds/linux.git>/master (1 IPMI fix, 1 acpi_osi=! support)
2. 11 patches in <kernel/git/rafael/linux-pm.git>/linux-next (11 IPMI fixes and cleanups)
3. 2 additional patches (2 IPMI fixes, also fixed the issue 2 mentioned in comment 16)

If you want to try, please:
1. apply these patches
2. make sure CONFIG_SENSORS_ACPI_POWER / CONFIG_IPMI_SI is "m"
3. boot the kernel with "acpi_osi=! acpi_osi=Linux"
If you still see problems during boot, then:
4. type "modprobe acpi_power_meter" after boot

The last issue is a deferred probing issue related to the acpi_power_meter:
 If the probing order is wrong, the acpi_power_meter driver might not work.
It is not related to the IPMI fixes series.

Created attachment 112611 [details]
acpi_osi=! and IPMI fixes

I found one more dependent OSI patch.
Let me post again, sorry for the noise.

(In reply to Lv Zheng from comment #37)

> It seems only \_OSI can make TOOS to be 0x01,0x07,0x08.  The BIOS setting
> might not work.

Yes, you are right, now I learned some IPMI.
After I play around IPMI and iDRAC settings, the Errors' still there.

On the other hand, after manually load some modules
  modprobe ipmi_si
  modprobe ipmi_msghandler
  modprobe ipmi_devintf
Seems ipmitool works correctly.

So what this bug affect?

----------------------
So I just need to apply attachment 112611 [details] (to 3.10 kernel), than follow Comment 39 ?

Created attachment 113171 [details]
dmesg - kernel that applied attachment 112611 [details] - Dell R820

It still shows the ipmi error. Is it expected result? Or, am I doing something wrong?

I did following:
# get kernel source for debian
dget -u http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.10.11-1~bpo70+1.dsc
# (cd linux_3.10.11 then) apply patches
patch -p1 < ../../ipmi-recent-fixes/acpi-ipmi01.patch
....(all succeeded. Only one say: Hunk #1 succeeded at 1144 with fuzz 2 (offset -15 lines).)
# confirm the variable is "m"
$ grep -R CONFIG_SENSORS_ACPI_POWER .
./debian/config/kernelarch-x86/config:CONFIG_SENSORS_ACPI_POWER=m
$ grep -R CONFIG_IPMI_SI .
./debian/config/kernelarch-x86/config:CONFIG_IPMI_SI=m
#commit
dch --nmu "ACPI-IPMI bug new."
dpkg-source --commit
# build the kernel
dpkg-buildpackage -us -uc -j32
# install it
sudo dpkg -i linux-image-3.10-0.bpo.3-amd64_3.10.11-1~bpo70+1.1_amd64.deb
# add acpi_osi=! acpi_osi=Linux
sudo vi /etc/default/grub
sudo update-grub
sudo reboot

I still cannot find a working ipmi_si on your system in the boot log.
After booting, can you find the following PNPIDs under /sys/bus/acpi/devices:
  ACPI000D
  IPI0001
I believe the IPI0001 device is there as I can see the following log entry indicating the IPI0001 PnP device is added by the PnP bus:
  system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
                                               ^^^^^^^
And I believe the ACPI000D device is there according to the error messages you are reporting.

If they are all there,  you need to type the following commands after boot:
  echo 00:07 > /sys/bus/pnp/drivers/system/unbind
       ^^^^^
  modprobe ipmi_si
           ^^^^^^^
  modprobe acpi_power_meter
           ^^^^^^^^^^^^^^^^
Where 00:07 is got from the following line:
  system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
         ^^^^^
If it changed during the new boot, please change it to the value matches IPI0001.

After execution of the above commands, please check the dmesg again to see if the above patches are working.
You may find this time the acpi_power_meter is working and there shouldn't be the following error message dumped by the dmesg again:
  ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
The following command lines should appear in your log:
  ipmi 00:07: IPMI kcs interface initialized

If you reached here and got acpi_power_meter worked succesfully, you should have done with this thread. :-)

This is what I was working for and the patchset has solved.  It solved crashes occurred in the acpi_ipmi module and installed acpi_ipmi from the ACPI namespace root node so that IPMI region handler could be found for a device not under the scope of IPI0001.  

--------------------

As your problem is related to the PNP0c01, not IPI0001 (so it shouldn't be an ACPI bug or IPMI bug, your case is a PnP bug or a driver core bug), I suggest you to start another thread to report the following issue:
If both PNP0c01 and IPI0001 were marked for the local BMC, Linux could not automatically match the "ipmi_si" driver (drivers/char/ipmi/ipmi_si_intf.c) but match the "system" driver (drivers/pnp/system.c) for the device instead.
    Device (NIPM)
    {
        Name (_HID, EisaId ("IPI0001"))  // _HID: Hardware ID
                             ^^^^^^^
        Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
                             ^^^^^^^
I checked all of the PNPIDs related to PNP0c01 and IPI0001, got the following proof:
  system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
  ^^^^^^                                       ^^^^^^^ ^^^^^^^
The "system" driver gets higher precedence to be matched for your IPMI local BMC.
    static const struct pnp_device_id pnp_dev_table[] = {
        /* General ID for reserving resources */
        {"PNP0c02", 0},
        /* memory controller */
        {"PNP0c01", 0},
          ^^^^^^^
        {"", 0}
    };

It looks to me like the "system" driver is a wrong approach or Linux driver core need to be improved.  This is another issue and I'm not a PnP expert, so you need to ask PnP guys to check if drivers/pnp/system.c can be changed from a PnP driver to a functional module to reserve resources.

--------------------

If you can finally find the following lines in the boot log, 
  ipmi_si: probing via ACPI
  ipmi_si: Adding ACPI specified kcs state machine
  ipmi 00:07: IPMI kcs interface initialized
and the following lines disappeared:
  system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
  ACPI Error: No handler for Region [SYSI] (ffff8810790cb540) [IPMI] (20130328/evregion-161)
  ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
  ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node ffff8830794b4740), AE_NOT_EXIST (20130328/psparse-537)
  ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node ffff8830794b4718), AE_NOT_EXIST (20130328/psparse-537)
Then, all of your issues can be solved.

--------------------

Another way to achieve this might be:
You can take this as a BIOS bug for your particular machine and perform a DSDT customization with the following line deleted for Linux:
    Device (NIPM)
    {
        Name (_HID, EisaId ("IPI0001"))  // _HID: Hardware ID
        Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then boot and try again.

(In reply to Lv Zheng from comment #43)
> I still cannot find a working ipmi_si on your system in the boot log.
> After booting, can you find the following PNPIDs under /sys/bus/acpi/devices:
>   ACPI000D
>   IPI0001

I can find these:
$ ls /sys/bus/acpi/devices | grep PI000
ACPI000C:00
ACPI000D:00
IPI0001:00


> I believe the IPI0001 device is there as I can see the following log entry
> indicating the IPI0001 PnP device is added by the PnP bus:
>   system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
>                                                ^^^^^^^
> And I believe the ACPI000D device is there according to the error messages
> you are reporting.
> 
> If they are all there,  you need to type the following commands after boot:
>   echo 00:07 > /sys/bus/pnp/drivers/system/unbind
>        ^^^^^
>   modprobe ipmi_si
>            ^^^^^^^
>   modprobe acpi_power_meter
>            ^^^^^^^^^^^^^^^^
> Where 00:07 is got from the following line:
>   system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
>          ^^^^^
> If it changed during the new boot, please change it to the value matches
> IPI0001.
> 
> After execution of the above commands, please check the dmesg again to see
> if the above patches are working.
> You may find this time the acpi_power_meter is working and there shouldn't
> be the following error message dumped by the dmesg again:
>   ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
> The following command lines should appear in your log:
>   ipmi 00:07: IPMI kcs interface initialized
> 
> If you reached here and got acpi_power_meter worked succesfully, you should
> have done with this thread. :-)
> 

done all these:
# echo 00:07 > /sys/bus/pnp/drivers/system/unbind
# modprobe ipmi_si
# modprobe acpi_power_meter
# reboot

But after reboot, the error is still there:
# cat /var/log/dmesg | grep 'Error: Region'
[    5.354954] ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
acpi_power_meter is loaded, but ipmi_si is not (same as before)
# lsmod | grep acpi_power_meter
acpi_power_meter       13348  0 
# lsmod | grep ipmi_si


> As your problem is related to the PNP0c01, not IPI0001 (so it shouldn't be
> an ACPI bug or IPMI bug, your case is a PnP bug or a driver core bug), I
> suggest you to start another thread to report the following issue:

I reported it here: https://bugzilla.kernel.org/show_bug.cgi?id=64861


> --------------------
> 
> If you can finally find the following lines in the boot log, 
>   ipmi_si: probing via ACPI
>   ipmi_si: Adding ACPI specified kcs state machine
>   ipmi 00:07: IPMI kcs interface initialized
> and the following lines disappeared:
>   system 00:07: Plug and Play ACPI device, IDs IPI0001 PNP0c01 (active)
>   ACPI Error: No handler for Region [SYSI] (ffff8810790cb540) [IPMI]
> (20130328/evregion-161)
>   ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
>   ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node
> ffff8830794b4740), AE_NOT_EXIST (20130328/psparse-537)
>   ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node
> ffff8830794b4718), AE_NOT_EXIST (20130328/psparse-537)
> Then, all of your issues can be solved.
> 

this gives zero result:
# cat /var/log/dmesg | grep 'ipmi'


> --------------------
> 
> Another way to achieve this might be:
> You can take this as a BIOS bug for your particular machine and perform a
> DSDT customization with the following line deleted for Linux:
>     Device (NIPM)
>     {
>         Name (_HID, EisaId ("IPI0001"))  // _HID: Hardware ID
>         Name (_CID, EisaId ("PNP0C01"))  // _CID: Compatible ID
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Then boot and try again.

Mark~, will try this later.

(In reply to eddy from comment #44)

> done all these:
> # echo 00:07 > /sys/bus/pnp/drivers/system/unbind
> # modprobe ipmi_si
> # modprobe acpi_power_meter
> # reboot

Please check dmesg before typing "reboot" and after typing "modprobe acpi_power_meter".  You should see the following lines:
   ipmi_si: probing via ACPI
   ipmi_si: Adding ACPI specified kcs state machine
   ipmi 00:07: IPMI kcs interface initialized
And there shouldn't be the following log entries after the above "ipmi_si" ones:
   ACPI Error: No handler for Region [SYSI] (ffff8810790cb540) [IPMI] (20130328/evregion-161)
   ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
   ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node ffff8830794b4740), AE_NOT_EXIST (20130328/psparse-537)
   ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node ffff8830794b4718), AE_NOT_EXIST (20130328/psparse-537)

These commands cannot help you to solve your issue but can tell you the root cause for your issue.

(In reply to Lv Zheng from comment #45)

Oh, sorry, before reboot, I misunderstand. Here it is...

# echo 00:07 > /sys/bus/pnp/drivers/system/unbind
# lsmod | grep ipmi_si
# lsmod | grep acpi_power_meter
acpi_power_meter       13348  0 
# modprobe ipmi_si
# dmesg | tail -n 16
[  268.278982] ipmi message handler version 39.2
[  268.294188] Region 7 installed
[  268.294191] Region 7 registered
[  268.294221] IPMI System Interface driver.
[  268.294370] ipmi_si: probing via ACPI
[  268.294435] ipmi_si 00:07: [io  0x0ca8] regsize 1 spacing 4 irq 10
[  268.294437] ipmi_si: Adding ACPI-specified kcs state machine
[  268.294463] ipmi_si: probing via SMBIOS
[  268.294465] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 10
[  268.294467] ipmi_si: Adding SMBIOS-specified kcs state machine duplicate interface
[  268.294472] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca8, slave address 0x0, irq 10
[  268.410948] ipmi_si 00:07: Using irq 10
[  268.412658] ipmi_si 00:07: Couldn't set irq info: cc.
[  268.412667] ipmi_si 00:07: Maybe ok, but ipmi might run very slowly.
[  268.422896] ipmi_si 00:07: Found new BMC (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
[  268.422922] ipmi_si 00:07: IPMI kcs interface initialized
# modprobe acpi_power_meter
# dmesg | tail -n 16
> > nothing changed
# modprobe -r acpi_power_meter
# modprobe acpi_power_meter
# dmesg | tail -n 1
[  612.068343] power_meter ACPI000D:00: Found ACPI power meter.

(In reply to eddy from comment #46)

Thanks for reporting. :-)

1. the usage model:
The acpi_power_meter device on your platform is implemented by ACPI BIOS.
Its functionalities are implemented through IPMI operation accesses.  An ACPI enumerated local BMC driver (ipmi_si) should register the IPMI region handler for it in order to offer such functionalities.

2. my mistakes:
A. removing acpi_power_meter driver
> # lsmod | grep acpi_power_meter
> acpi_power_meter       13348  0
...
> # modprobe -r acpi_power_meter
> # modprobe acpi_power_meter

Thanks for noticing the issue in my replies that I should tell you to remove acpi_power_meter driver before "modprobe ipmi_si" but not and thanks for trying my suggestion in correct way by executing "modprobe -r acpi_power_meter".

This also reminds me that there are issues like "deferred probing" still existing for the acpi_power_meter driver.

B. listing ipmi_si driver
> [  268.422922] ipmi_si 00:07: IPMI kcs interface initialized

If you executes "lsmod | grep ipmi_si" after this, the ipmi_si should be listed as a loaded module.

3. so the correct execution order might be:
A. removing drivers that have been loaded in the wrong order
   # echo 00:07 > /sys/bus/pnp/drivers/system/unbind
   # modprobe -r acpi_power_meter
   # modprobe -r ipmi_si
B. confirming the absence of the targeted drivers
   # lsmod | grep ipmi_si
   # lsmod | grep acpi_power_meter
C. inserting the targeted drivers and confirming their presence
   # modprobe ipmi_si
   # lsmod | grep ipmi_si
   # modprobe acpi_power_meter
   # lsmod | grep ipmi_si
D. using acpi_power_meter
   I don't have experiences of using acpi_power_meter, my tests are just done against a pseudo device, so my suggestion might be wrong.
   You might be able to find new attribute files created under "/sys/bus/acpi/devices/ACPI000D" like "power1_xxx" or you could reach such files through the "physical_node" link under this node.
   You could cat such attribute files for more testing.
E. stress testing of hotplugging
   This relates to the testability of knowing the quality of the patches posted in this thread, it doesn't relate to any of your issues.
   My unit tests were done by invoking a script from several processes to do endless and concurrent "cat" operations on such attribute files.  And exeuting another script to "insmod"/"rmmod" "acpi_ipmi" module frequently to perform a stress test for hotplugging.
    In your case where "acpi_ipmi" module has been merged to the "ipmi_si", the test might also be able to be achieved by using "/sys/modules/ipmi_si/parameters/hotmod".  But I haven't tried.  The usage of ipmi_si hotmod is documented in the Documentation/IPMI.txt.  If you have interests on the stress test, you need to take a look at this document.
F. dumping kernel logs
   # dmesg > dmesg.output
   You could also post this dmesg output here so that we could check if any further issues are still there for the patches in this thread.

4. the test result:
> [  268.294188] Region 7 installed
> [  268.294191] Region 7 registered

These messages showed us that the ACPI IPMI region handler is successfully installed.

> # dmesg | tail -n 1
> [  612.068343] power_meter ACPI000D:00: Found ACPI power meter.

The result is expected.  But since it is zapped to only 1 line, I couldn't see if the following errors messages are still there.
   ACPI Error: No handler for Region [SYSI] (ffff8810790cb540) [IPMI] (20130328/evregion-161)
   ACPI Error: Region IPMI (ID=7) has no handler (20130328/exfldio-305)
   ACPI Error: Method parse/execution failed [\_SB_.PMI0._GHL] (Node ffff8830794b4740), AE_NOT_EXIST (20130328/psparse-537)
   ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMC] (Node fff8830794b4718), AE_NOT_EXIST (20130328/psparse-537)
When acpi_power_meter requests the IPMI region accesses, if no error occurred again like the above, then patches posted in this thread should be working well now.

Closed due to most of the code has been shipped in Linux main stream.

I seem to have this problem on 3.19.6:

[At 11.582715] [info] IPMI SSIF Interface driver
[At 11.583038] [warning] ACPI Error: No handler for Region [SYSI] (ffff88041f89b1b0) [IPMI] (20141107/evregion-163)
[At 11.583043] [warning] ACPI Error: Region IPMI (ID=7) has no handler (20141107/exfldio-299)
[At 11.583047] [warning] ACPI Error: Method parse/execution failed [\x5c_SB_.PMI0._GHL] (Node ffff88041f89adc0), AE_NOT_EXIST (20141107/psparse-536)
[At 11.583055] [warning] ACPI Error: Method parse/execution failed [\x5c_SB_.PMI0._PMC] (Node ffff88041f89ad20), AE_NOT_EXIST (20141107/psparse-536)
[At 11.583061] [warning] ACPI Exception: AE_NOT_EXIST, Evaluating _PMC (20141107/power_meter-755)

I have acpi_power_meter, ipmi_si, and acpi_ipmi built as modules.  Reloading acpi_power_meter triggers the warnings again even if the ipmi modules are loaded AFAICT.  I'll attach my DSDT.

Created attachment 175391 [details]
DSDT on affected system

Lv, I am still seeing warnings.

> Installing Debian 9 with Linux 4.9.x and CentOS 7 with Linux 3.10.x on a 
> Dell PowerEdge R730.
> 
> In both versions the Linux kernel reports the errors below.
> 
> ```
> […]
> kernel: ipmi message handler version 39.2 kernel: IPMI System Interface 
> driver.
> kernel: ipmi_si: probing via SMBIOS
> kernel: ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 10 kernel: 
> ipmi_si: Adding SMBIOS-specified kcs state machine
> kernel: ipmi_si: Trying SMBIOS-specified kcs state machine at i/o 
> address 0xca8, slave address 0x20, irq 10 kernel: wmi: Mapper loaded
> kernel: ACPI Error: No handler for Region [SYSI] (ffff8fbcdec42090) 
> [IPMI] (20160831/evregion-166)
> kernel: ACPI Error: Region IPMI (ID=7) has no handler (20160831/exfldio-299)
> kernel: ACPI Error: Method parse/execution failed [\_SB.PMI0._GHL] (Node 
> ffff8fb4df4a0eb0), AE_NOT_EXIST (20160831/psparse-543)
> kernel: ACPI Error: Method parse/execution failed [\_SB.PMI0._PMC] (Node 
> ffff8fb4df4a0348), AE_
> […]
> kernel: (NULL device *): The BMC does not support setting the recv irq 
> bit, compensating, but the BMC needs to be fixed.
> ```

Should I create separate issues for these, or should this issue be reopened?

Same issue still appears on 6.0.12

[   30.114593] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[   30.114652] ACPI Error: No handler for Region [SYSI] (000000001278fbb1) [IPMI] (20220331/evregion-130)
[   30.114734] ACPI Error: Region IPMI (ID=7) has no handler (20220331/exfldio-261)
[   30.114804] ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20220331/psparse-529)
[   30.114885] ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20220331/psparse-529)
[   30.114965] ACPI: \_SB_.PMI0: _PMC evaluation failed: AE_NOT_EXIST



adding additional kernel modules as per the suggestion here
https://community.hpe.com/t5/proliant-servers-ml-dl-sl/kernel-acpi-error-ae-not-exist-region-ipmi-region-powr-sb-pmi0/td-p/7179187

did not help.

Created attachment 303435 [details]
Dell PowerEdge R620 acpi tables

As the issue is closed, please create a separate bug report, or even contact the subsystem mailing list. Additionally, please attach the Linux messages (`dmesg`), and also open up a call with Dell, as in my opinion, they should also check that there are no errors and warnings with the devices they ship.

(In reply to Lv Zheng from comment #43)
> ...
> As your problem is related to the PNP0c01, not IPI0001 (so it shouldn't be
> an ACPI bug or IPMI bug, your case is a PnP bug or a driver core bug), I
> suggest you to start another thread to report the following issue:
> If both PNP0c01 and IPI0001 were marked for the local BMC, Linux could not
> automatically match the "ipmi_si" driver (drivers/char/ipmi/ipmi_si_intf.c)
> but match the "system" driver (drivers/pnp/system.c) for the device instead.
> ...

ThX for a hint! Without this detailed analysis probably I would not, be able to think and produce something working (not sure is this method correct, but power meter shows in hwmon)

I posted a patch in new bug reported: https://bugzilla.kernel.org/show_bug.cgi?id=64861