Bug 102421

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

I also posted a message on linux-acpi: https://marc.info/?l=linux-acpi&m=143946499520914&w=2 , and ready to help solve the problem.

If you mean this:
[    0.208510] ACPI Error: No handler for Region [RAM_] (ffff88015a0bb3a8) [EmbeddedControl] (20150410/evregion-163)
[    0.208521] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150410/exfldio-297)
[    0.208529] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff88015a0bac80), AE_NOT_EXIST (20150410/psparse-536)
[    0.208904] ACPI Error: No handler for Region [RAM_] (ffff88015a0bb3a8) [EmbeddedControl] (20150410/evregion-163)
[    0.208910] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150410/exfldio-297)
[    0.208916] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff88015a0bac80), AE_NOT_EXIST (20150410/psparse-536)

OK. I'll check to see what's happening there.

Thanks and best regards
-Lv

Yes, I mean this.

This is definitely the known ECDT bug.
Linux support of ECDT is completely wrong since Alexey starts to introduce quirks to pre-load DSDT EC in case of ECDT is incorrect or doesn't exist.
This is one of the examples that Linux actually doesn't support ACPI 2.0 features.

Thanks and best regards
-Lv

In order to understand this correctly, I tracked back the ec.c commit log to learn what's happening there for so many ECDT quirks.

Here is the result:

1. Pre-loaded DSDT EC
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=9916
   Reporter: Jiri Kosina <jikos@jikos.cz>
   Machine: Lenovo ThinkPad X61s
   DSDT: \_SB.PCI0.LPC.EC
   ECDT: \_SB.PCI0.LPC.EC
   _REG: Store(Arg1, \H8DR)
   \_H8DR: Default is Zero, set to One very early in \_SB._INI when _REV >= 2.
   Root cause: Shouldn't register EC GPE handler in early stage.
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=208c70a
   New fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2044702

2. Pre-loaded DSDT EC is broken/reworked
   Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10100
             https://lkml.org/lkml/2008/2/25/282
   Reporter: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
   Machine: Lenovo ThinkPad T61p
            DSDT: https://lkml.org/lkml/2008/2/25/337
   Root cause: Shouldn't register _Qxx handlers in early stage.
   DSDT: \_SB.PCI0.LPC.EC
   ECDT: \_SB.PCI0.LPC.EC
   _REG: Store(Arg1, \H8DR)
   \_H8DR: Default is Zero, set to One very early in \_SB._INI when _REV >= 2.
   Old Fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4af8e10
   New fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce52ddf

3. Wrong ECDT - reversed
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=9399
   Reporter: Milo Casagrande
   Machine: Asus L4R, Asus M6R
   DSDT: \_SB.PCI0.SBRG.EC0
   ECDT: \_SB.PCI0.SBRG.EC0
   _REG: Store (Arg1, \_SB.PCI0.SBRG.EC0.REGC)
   \_SB.PCI0.SBRG.EC0.REGC: Default is Zero, returned from \_SB.PCI0.SBRG.EC0.ECAV.
   \_SB.PCI0.SBRG.EC0.ECAV: Return One  If (_REG(0x03, Ones) && _REV >= 2) || _REG(0x03,  One)
                            Return Zero If (_REG(0x03, Ones) && _REV <  2) || _REG(0x03, zero)
                            When ECAV returns Zero, sometimes port 0x66 (EC command/status register) is directly accessed, sometimes no-op.
   Root cause: ECDT is broken. The command/data IO port addresses are reversed.
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2500822
   New fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6cb0e8

4. Wrong ECDT - dummy
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11880
   Reporter: <admin@movzx.org>
   Machine: Asus X50GL
   DSDT: \_SB.PCI0.SBRG.EC0
   ECDT: \_SB.PCI0.ISA.EC
   _REG: Store (Arg1, \_SB.PCI0.SBRG.EC0.ECFL)
   \_SB.PCI0.SBRG.EC0.ECFL: Default is Ones, returned from \_SB.PCI0.SBRG.EC0.ECAV
   \_SB.PCI0.SBRG.EC0.ECAV: Return  One If _REV >= 2 || ECFL ==  One
                            Return Zero If _REV <  2 || ECFL == Ones || ECFL == Zero
                            When ECAV returns Zero, always no-op.
   Root cause: ECDT is broken. Both the command/data I/O port addresses and GPE are zero. EC Namepath is incorrect.
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5279de

5. Limit pre-loaded DSDT EC to Asus
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11884
   Reporter: Alex Shumakovitch <shurik@gwu.edu>
   Machine: HP EliteBook 2730p
   DSDT: \_SB.PCI0.LPCB.EC0
   ECDT: N/A
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=235c4a5

6. Wrong ECDT - reversed
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=12461
   Reporter: John Morris <mailjohnmorris@gmail.com>
   Machine: MSI MS-171F
   DSDT: \_SB.PCI0.SBRG.EC0
   ECDT: \_SB.PCI0.SBRG.EC0
   _REG: Store (Arg1, \_SB.PCI0.SBRG.EC0.MYEC)
   \_SB.PCI0.SBRG.MYEC: Default is One.
   Root cause: ECDT is broken. The command/data IO port addresses are reversed.
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a5032bf

7. Broken MSI quirk
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=14081
   Reporter: Ryan Underwood <nemesis@icequake.net>
   Machine: HP Pavilion dv2700
   Root cause: DMI table includes "Notebook" which matches MSI quirk
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0adf3c7

8. ECDT probe code execute control method too early
   Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=14086
   Reporter: Maxim Levitsky <maximlevitsky@gmail.com>
   Machine: Acer Aspire 5720G
   DSDT: \LPCB.EC0
   ECDT: N/A
   _REG: Store (Arg1, \LPCB.EC0.Z009)
   Root cause: _REG shouldn't be invoked (but not fixed correctly)
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=478fa03

9. Broken MSI quirk
   Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=14446
   Reporter: Eddy Petrișor <eddy.petrisor+linbug@gmail.com>
   Machine: MSI S271
   Root cause: 
   Old fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=55b313f

It looks like that:
After ACPI 2.0 where ECDT is introduced, the BIOSes that contain the ECDT will make the named object's value that originally is flagged in EC._REG() flagged very early (either default is flagged or flagged in _SB._INI) in order to have all _INI control methods invoked with EC operation region accessibility. This is one of the key ACPI 2.0 features.
And this implies that, after ACPI 2.0, before executing all _INI control methods (after ACPI 2.0, there are module level AML), BIOSes has already a deal with OSPMs in the spec that there shouldn't be any control methods executed before _SB._INI. Which means: for EC, in order to support ECDT in early stage, when ECDT is probed, it:
1. Shouldn't handle SCI_EVT in order not to execute any _Qxx;
2. Shouldn't invoke _REG but should still make the region handler ready;
3. Shouldn't visit any namespace objects (either _GPE/_CRS) or the EC device itself since it shouldn't think the namespace is ready at this point.
Thus BTW, the GPE information and EC device path information in ECDT actually is useless for ECDT support.

As a conclusion, many of the above commits are wrong, the root cause should be: _REG shouldn't be executed during early stage while the fixes walked into the dead end by visitting more namespace objects.
I'll provide a fix later for you to test.

Thanks and best regards
-Lv

For this bug, there are 2 issues:

1. The error occurs before moudule level execution, which should be from acpi_ec_ecdt_probe(). In acpi_ec_ecdt_probe, if there is no ECDT found on the platform, the namespace EC shouldn't be used. This can prevent the error log from being dumped.
2. The error may still occur when the _REG method is invoked during the late stage. And we need to check what would be the effect if the first had been fixed.

Thanks and best regards
-Lv

In order to fix the first issue, we need:

1. Add an param to acpi_install_address_space_handlers, indicating early stage and skip _REG execution for early stage.
2. In Linux ec driver, restore the code to invoke ec_remove_handlers() for ECDT and invoke ec_install_handlers() again for the DSDT EC.
3. Maybe we need also tune ACPICA region handler installation code, stop attaching the handler object to the region object, but in the region access code, find the region handler object from its parent nodes. We may not do this right now, currently, ACPICA table loading is split into 2 stages and namespace objects are ready because of acpi_load_tables() invoked earlier than acpi_ec_ecdt_probe().

I'm going to try 1 and 2, and post the fix here.

Thanks and best regards
-Lv

Created attachment 189071 [details]
[PATCH] ACPI / EC: Remove early namespace reference from EC

The fix patch, applying on latest kernel.

Thanks and best regards
-Lv

Do you mean 4.2.2 or 4.3-rc3 as latest?

(In reply to Lv Zheng from comment #9)
> Created attachment 189071 [details]

Lv, I applied the patch to git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

dmesg output is bellow and seems nothing changed:

[    0.000000] BIOS-e820: [mem 0x000000009cebf000-0x000000009cfbefff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000009cfbf000-0x000000009cffefff] ACPI data
[    0.000000] reserve setup_data: [mem 0x000000009cebf000-0x000000009cfbefff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x000000009cfbf000-0x000000009cffefff] ACPI data
[    0.000000] efi:  SMBIOS=0x9c743000  ESRT=0x9c84f018  ACPI 2.0=0x9cffe014 
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x000000009CFFE014 000024 (v02 ACRSYS)
[    0.000000] ACPI: XSDT 0x000000009CFCB188 0000DC (v01 ACRSYS ACRPRDCT 00000001      01000013)
[    0.000000] ACPI: FACP 0x000000009CFEF000 00010C (v05 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: DSDT 0x000000009CFD7000 01110B (v02 ACRSYS ACRPRDCT 00000000 1025 00040000)
[    0.000000] ACPI: FACS 0x000000009CFB8000 000040
[    0.000000] ACPI: UEFI 0x000000009CFFD000 000236 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: UEFI 0x000000009CFFC000 000042 (v01 ACRSYS ACRPRDCT 00000000 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFF8000 0031AA (v01 ACRSYS ACRPRDCT 00001000 1025 00040000)
[    0.000000] ACPI: MSDM 0x000000009CFF7000 000055 (v03 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFF4000 002FDE (v02 ACRSYS ACRPRDCT 00001000 1025 00040000)
[    0.000000] ACPI: ASF! 0x000000009CFF3000 0000A5 (v32 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: ASPT 0x000000009CFF2000 000034 (v07 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: BOOT 0x000000009CFF1000 000028 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: DBGP 0x000000009CFF0000 000034 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: HPET 0x000000009CFEE000 000038 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: LPIT 0x000000009CFED000 000094 (v01 ACRSYS ACRPRDCT 00000000 1025 00040000)
[    0.000000] ACPI: APIC 0x000000009CFEC000 00008C (v03 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: MCFG 0x000000009CFEB000 00003C (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: WDAT 0x000000009CFEA000 000224 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFD5000 0013C4 (v02 ACRSYS ACRPRDCT 00001000 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFE9000 000250 (v02 ACRSYS ACRPRDCT 00000000 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFD4000 000410 (v02 ACRSYS ACRPRDCT 00003000 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFD3000 000B74 (v02 ACRSYS ACRPRDCT 00003000 1025 00040000)
[    0.000000] ACPI: SSDT 0x000000009CFCD000 005CEB (v02 ACRSYS ACRPRDCT 00003000 1025 00040000)
[    0.000000] ACPI: DMAR 0x000000009CFCC000 0000B0 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: FPDT 0x000000009CFCA000 000044 (v01 ACRSYS ACRPRDCT 00000002 1025 00040000)
[    0.000000] ACPI: BGRT 0x000000009CFC9000 000038 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000101] ACPI: Core revision 20150818
[    0.056731] ACPI: 8 ACPI AML tables successfully acquired and loaded
[    0.160184] PM: Registering ACPI NVS region [mem 0x9cebf000-0x9cfbefff] (1048576 bytes)
[    0.164058] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.164062] ACPI: bus type PCI registered
[    0.164065] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.169554] ACPI: Added _OSI(Module Device)
[    0.169558] ACPI: Added _OSI(Processor Device)
[    0.169561] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.169564] ACPI: Added _OSI(Processor Aggregator Device)
[    0.176418] ACPI Error: No handler for Region [RAM_] (ffff88015a0c4048) [EmbeddedControl] (20150818/evregion-163)
[    0.176428] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150818/exfldio-297)
[    0.176437] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff88015a0c3c80), AE_NOT_EXIST (20150818/psparse-542)
[    0.176794] ACPI Error: No handler for Region [RAM_] (ffff88015a0c4048) [EmbeddedControl] (20150818/evregion-163)
[    0.176800] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150818/exfldio-297)
[    0.176806] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff88015a0c3c80), AE_NOT_EXIST (20150818/psparse-542)
[    0.180791] ACPI: Executed 17 blocks of module-level executable AML code
[    0.195199] ACPI: Dynamic OEM Table Load:
[    0.195229] ACPI: SSDT 0xFFFF880159292000 0003D3 (v02 PmRef  Cpu0Cst  00003001 INTL 20130117)
[    0.197541] ACPI: Dynamic OEM Table Load:
[    0.197568] ACPI: SSDT 0xFFFF880159273000 0005AA (v02 PmRef  ApIst    00003000 INTL 20130117)
[    0.199979] ACPI: Dynamic OEM Table Load:
[    0.200002] ACPI: SSDT 0xFFFF88015928BA00 000119 (v02 PmRef  ApCst    00003000 INTL 20130117)
[    0.204271] ACPI: Interpreter enabled
[    0.204293] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150818/hwxface-580)
[    0.204313] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150818/hwxface-580)
[    0.204374] ACPI: (supports S0 S3 S4 S5)
[    0.204378] ACPI: Using IOAPIC for interrupt routing
[    0.204455] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.205746] ACPI: Power Resource [PG00] (on)
[    0.206839] ACPI: Power Resource [PG01] (on)
[    0.207898] ACPI: Power Resource [PG02] (on)
[    0.238586] ACPI Error: No handler for Region [RAM_] (ffff88015a0c4048) [EmbeddedControl] (20150818/evregion-163)
[    0.238596] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150818/exfldio-297)
[    0.238604] ACPI Error: Method parse/execution failed [\_SB.LID0._PSW] (Node ffff88015a0c61e0), AE_NOT_EXIST (20150818/psparse-542)
[    0.238618] ACPI: _PSW execution failed
[    0.252974] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
[    0.252989] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    4.296933] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[    4.296939] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[    4.302397] pci 0000:00:14.0: System wakeup disabled by ACPI
[    4.304016] pci 0000:00:1b.0: System wakeup disabled by ACPI
[    4.304850] pci 0000:00:1c.0: System wakeup disabled by ACPI
[    4.307883] pci 0000:00:1d.0: System wakeup disabled by ACPI
[    4.311472] pci 0000:01:00.0: System wakeup disabled by ACPI
[    4.318517] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.318634] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.318746] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.318855] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.318964] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.319073] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.319191] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.319300] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    4.325618] ACPI: Enabled 6 GPEs in block 00 to 7F
[    4.325710] ACPI : EC: GPE = 0x2f, I/O: command/status = 0x66, data = 0x62
[    4.325723] ACPI : EC: EC started
[    4.333897] ACPI: bus type USB registered
[    4.334357] PCI: Using ACPI for IRQ routing
[    4.362850] pnp: PnP ACPI init
[    4.363313] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    4.363424] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
[    4.363519] system 00:02: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[    4.365406] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    4.367112] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    4.373272] pnp: PnP ACPI: found 5 devices
[    4.381626] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    5.937875] ACPI: AC Adapter [ADP1] (on-line)
[    5.938071] ACPI: Sleep Button [SLPB]
[    5.938180] ACPI: Power Button [PWRF]
[    5.941066] ACPI: Thermal Zone [TZS0] (53 C)
[    5.941584] ACPI: Thermal Zone [TZS1] (48 C)
[    5.943304] ACPI: Battery Slot [BAT0] (battery present)
[    7.221759] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   11.755432] ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F conflicts with OpRegion 0x0000000000003040-0x000000000000304F (\_SB_.PCI0.SBUS.SMBI) (20150818/utaddress-254)
[   11.755443] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[   12.353020] acer_wmi: Acer Laptop ACPI-WMI Extras

OK,
Let's start from the very first step.
Finding the stacked callers.
Let me post a debugging patch later.

Thanks and best regards
-Lv

Created attachment 189781 [details]
[PATCH] ACPICA: Executer: catch stacked callers of region accesses

The debugging patch.

Please apply the both patch (attachment 189071 [details] and attachment 189781 [details]) and try again.
Then upload the full dmesg here.
Thanks in advance.

Best regards
-Lv

Created attachment 189891 [details]
dmesg for two patches from comment #14

_REG is still invoked in acpi_ev_initialize_op_regions() before invoking _INI...
Let me attach another fix.

Thanks and best regards
-Lv

Could you also apply only attachment 189781 [details], do not apply attachment 189071 [details].
Then try again and upload the dmesg.
So that I can confirm if the attachment 189071 [details] has improved the situation.

Thanks and best regards
-Lv

Created attachment 190091 [details]
dmesg for only attachment 189781 [details] patch

(In reply to Nicholas from comment #18)
> Created attachment 190091 [details]
> dmesg for only attachment 189781 [details] patch

I couldn't see what I want in this dmesg.
So I got a bit confused by the issue.
Let me improve the debugging patch to have more stuff invoked.
Sorry for this.

Thanks and best regards
-Lv

Created attachment 190811 [details]
[PATCH] ACPICA: Executer: catch stacked callers of region accesses

The updated debugging patch to catch the failure point.

Could you help to redo the test mentioned in comment 17 using the updated patch - attachment 190811 [details]?
Thanks in advance.

Best regards
-Lv

Created attachment 191061 [details]
dmesg in reply to comment #21

Great!
Let me check the log and reply later.

Thanks
-Lv

According to Lv, this seems like a module level code support issue.
Will re-test after the module level support patches finished.

Created attachment 210931 [details]
dmesg on MSI-GS40-6qe, kernel 4.6-rc1 ACPI errors

Hello,

I have some ACPI errors on a MSI laptop.
It looks like the same error described here, so I didn't opened another ticket.
Tell me if I should.

Also, CPU fan and discrete graphic fan aren't detected by sensors-detect. Is it linked ?

best regards,

sdavid.

Most of the patches are upstreamed to linux-pm.git/bleeding-edge.
While 4 remained patches are not.
Please wait a bit longer.
I'll ping the maintainer.

Thanks
-Lv

Or you can help to confirm.
Please
1. clone the following git:
   # git clone git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
2. Check out the bleeding-edge branch.
   # git checkout bleeding-edge
3. apply the following 4 patches:
   https://patchwork.kernel.org/patch/8656631/
   https://patchwork.kernel.org/patch/8656681/
   https://patchwork.kernel.org/patch/8656691/
   https://patchwork.kernel.org/patch/8656671/
4. re-build and boot the kernel to see if the error messages are still there.
5. also upload the dmesg output after booting if the error persists.

Thanks in advance
-Lv

Created attachment 211781 [details]
dmesg on MSI-GS40-6qe, kernel 4.6-rc2 + patch ACPI errors

Hello,

I compiled the bleeding-edge branche from linux-pm.git with the 4 patches you've linked and here's the dmesg I obtain after a reboot on the kernel.

BTW, I still don't have any fan detected on my system.

I can do more tests if you have patch asides.

Thank you for your help.

Best regards,

sdavid.

I can test that in the weekend.

(In reply to Nicholas from comment #29)
> I can test that in the weekend.

Thanks in advance.
I can't find the errors you reported in sdavid's test.
Possibly the issue has been fixed.
But we need the original reporter's confirmation.

Best regards
-Lv

(In reply to sdavid from comment #28)
> Created attachment 211781 [details]
> dmesg on MSI-GS40-6qe, kernel 4.6-rc2 + patch ACPI errors

MSI-GS40-6qe is not the platform Nicholas was reporting.

> I compiled the bleeding-edge branche from linux-pm.git with the 4 patches
> you've linked and here's the dmesg I obtain after a reboot on the kernel.

I cannot find the errors in it now.

> BTW, I still don't have any fan detected on my system.

This doesn't sound like the same issue.
Could you file another bug and point us there.

Thanks and best regards
-Lv

Created attachment 212311 [details]
dmesg for patches from comment #27

Still have the errors.

I decompiled your acpidump, didn't find ECDT.
So this issue is not related to the ECDT order.

[    0.334837] ACPI: 8 ACPI AML tables successfully acquired and loaded

[    0.347052] ACPI Error: No handler for Region [RAM_] (ffff8801593e0090) [EmbeddedControl] (20160318/evregion-166)
[    0.347063] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160318/exfldio-299)
[    0.347071] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff8801593dfb18), AE_NOT_EXIST (20160318/psparse-542)

I checked the table.
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If (LEqual (Arg0, 0x03))
                {
                    Store (Arg1, ECOK)
                    If (LEqual (Arg1, One))
                    {
                        Store (One, EQEN)
                        Store (0x05, EOSS)
                        If (LEqual (OSYS, 0x03E8))
                        {
                            Store (0x40, OSTP)
                        }
                        Else
                        {
                            If (LAnd (LEqual (OSYS, 0x07D1), LEqual (OSYS, 0x07D2)))
                            {
                                Store (One, OSTP)
                            }
                            Else
                            {
                                If (LEqual (OSYS, 0x07D9))
                                {
                                    Store (0x03, OSTP)
                                }
                                Else
                                {
                                    If (LEqual (OSYS, 0x07DC))
                                    {
                                        Store (0x04, OSTP)
                                    }
                                    Else
                                    {
                                        If (LEqual (OSYS, 0x07DD))
                                        {
                                            Store (0x05, OSTP)
                                        }
                                        Else
                                        {
                                            Store (Zero, OSTP)
                                        }
                                    }
                                }
                            }
                        }
                    }
                    Else
                    {
                        MBEC (0x10, 0xFE, One)
                    }
                }

                ^^^GFX0.GLID (KLID, DPTN (One))
            }

It seems the ACPI table tries to access EC operation region inside of _REG.
Let me change a flag setting code in ACPICA to see if this can be allowed for your platform.

Thanks and best regards
-Lv

The test result seems incorrect.

[    0.310726] ACPI: Executed 17 blocks of module-level executable AML code

This indicates end of acpi_load_tables().

[    0.334837] ACPI: 8 ACPI AML tables successfully acquired and loaded

[    0.347052] ACPI Error: No handler for Region [RAM_] (ffff8801593e0090) [EmbeddedControl] (20160318/evregion-166)
[    0.347063] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160318/exfldio-299)
[    0.347071] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff8801593dfb18), AE_NOT_EXIST (20160318/psparse-542)
[    0.347430] ACPI Error: No handler for Region [RAM_] (ffff8801593e0090) [EmbeddedControl] (20160318/evregion-166)
[    0.347436] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160318/exfldio-299)
[    0.347441] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff8801593dfb18), AE_NOT_EXIST (20160318/psparse-542)

This should happen in EC probing or EC probing.
Before applying the patches, it can happen in ECDT EC probing.
But after applying the patches, it can only happen in DSDT EC probing.

[    0.353307] ACPI: Dynamic OEM Table Load:
[    0.353331] ACPI: SSDT 0xFFFF8801593C9400 0003D3 (v02 PmRef  Cpu0Cst  00003001 INTL 20130117)
[    0.355619] ACPI: Dynamic OEM Table Load:
[    0.355641] ACPI: SSDT 0xFFFF88015919A800 0005AA (v02 PmRef  ApIst    00003000 INTL 20130117)
[    0.358029] ACPI: Dynamic OEM Table Load:
[    0.358045] ACPI: SSDT 0xFFFF880159392600 000119 (v02 PmRef  ApCst    00003000 INTL 20130117)

According to my experiences, this happes in acpi_processor_set_pdc().

[    0.362300] ACPI: Interpreter enabled

Note that DSDT EC probing happens after this line.

So the test result is so strange to me.
Because after applying the patches, ECDT EC probing should happen before acpi_load_tables() not after it.
And after applying the patches, ECDT EC probing won't execute \_SB.PCI0.LPCB.EC0._REG because before acpi_load_tables(), no _REG will be allowed to be executed. In fact, no control methods are allowed to be executed.

So I cannot understand your test result.
Could you confirm it again.
Maybe you upload wrong dmesg output.
If the error happens for DSDT EC probing, I may believe that we still need fixes.
But applying the patches should have fixed the errors that happen in ECDT EC probing.

I'll also add a debug patch later for you to capature the stack from the error line.

Thanks
-Lv

Hi,

It seems we have this issue already debugged.

I can root cause the issue from the old dmesgs.

1. ACPICA code to trigger this:

According to attachment 191061 [details], the error is triggered when ACPICA initialize operation regions from acpi_ev_initialize_op_regions() invoked in acpi_initialize_objects():

[    0.177340] acpi_ev_execute_reg_methods - SystemMemory
...
[    0.177420]  [<ffffffff8142d563>] acpi_ev_initialize_op_regions+0x49/0x6e
[    0.177427]  [<ffffffff81d9823f>] acpi_initialize_objects+0x1e/0x4a
...
[    0.177890] ACPI Error: No handler for Region [RAM_] (ffff88015a0c4048) [EmbeddedControl] (20150818/evregion-163)
[    0.177899] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150818/exfldio-297)
[    0.177905] acpi_ex_access_region - EmbeddedControl
...
[    0.178074]  [<ffffffff8142d563>] acpi_ev_initialize_op_regions+0x49/0x6e
[    0.178081]  [<ffffffff81d9823f>] acpi_initialize_objects+0x1e/0x4a
...
[    0.178134] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff88015a0c3c80), AE_NOT_EXIST (20150818/psparse-542)
[    0.178152] acpi_ev_execute_reg_methods - SystemIO
...
[    0.178207]  [<ffffffff8142d563>] acpi_ev_initialize_op_regions+0x49/0x6e
[    0.178214]  [<ffffffff81d9823f>] acpi_initialize_objects+0x1e/0x4a
...
[    0.178631] ACPI Error: No handler for Region [RAM_] (ffff88015a0c4048) [EmbeddedControl] (20150818/evregion-163)
[    0.178637] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20150818/exfldio-297)
[    0.178642] acpi_ex_access_region - EmbeddedControl
...
[    0.178801]  [<ffffffff8142d563>] acpi_ev_initialize_op_regions+0x49/0x6e
[    0.178807]  [<ffffffff81d9823f>] acpi_initialize_objects+0x1e/0x4a
...
[    0.178857] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.EC0._REG] (Node ffff88015a0c3c80), AE_NOT_EXIST (20150818/psparse-542)

I can see that this happens to SystemMemory and SystemIo opregion initialization.

1. DSDT code to trigger this:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If (LEqual (Arg0, 0x03))
                {
                    Store (Arg1, ECOK)
                    If (LEqual (Arg1, One))
                    {
                        Store (One, EQEN)
                        Store (0x05, EOSS)
                        If (LEqual (OSYS, 0x03E8))
                        {
                            Store (0x40, OSTP)
                        }
                        Else
                        {
                            If (LAnd (LEqual (OSYS, 0x07D1), LEqual (OSYS, 0x07D2)))
                            {
                                Store (One, OSTP)
                            }
                            Else
                            {
                                If (LEqual (OSYS, 0x07D9))
                                {
                                    Store (0x03, OSTP)
                                }
                                Else
                                {
                                    If (LEqual (OSYS, 0x07DC))
                                    {
                                        Store (0x04, OSTP)
                                    }
                                    Else
                                    {
                                        If (LEqual (OSYS, 0x07DD))
                                        {
                                            Store (0x05, OSTP)
                                        }
                                        Else
                                        {
                                            Store (Zero, OSTP)
                                        }
                                    }
                                }
                            }
                        }
                    }
                    Else
                    {
                        MBEC (0x10, 0xFE, One)
                    }
                }

                ^^^GFX0.GLID (KLID, DPTN (One))

By executing this line, EC accesses will be resulted.
Note that this line if out of "If (LEqual (Arg0, 0x03))" check.
So it will be executed for the following invocations:
\_SB.PCI0.LPCB.EC0._REG(SystemMemory, One)
\_SB.PCI0.LPCB.EC0._REG(SystemIo, One)
            }

3. Why this is wrong:
According to spec, we actually needn't execute _REG(SystemMemory, One) or _REG(SystemIo, One).
According to my investigation using Windows, no such invocations can be seen from running a Windows on top of qemu.
So it seems that we should eliminate such wrong invocations.
This is a part of the order issue.

Let me post another fix for you to test on top of the others.

Thanks and best regards
-Lv

Created attachment 212341 [details]
[PATCH] ACPICA: Events: Add a new initialization flag to bypass system_memory/system_io operation region initialization

(In reply to Nicholas from comment #32)
> Created attachment 212311 [details]
> dmesg for patches from comment #27
> 
> Still have the errors.

Hi,

In addition to comment 27, please apply attachment 212341 [details] and try again.

Thanks
-Lv

Created attachment 212391 [details]
dmesg for the patches from comment #27 and #37

Nothing new

Sorry, the patch is wrong.
I introduced a new flag, but forgot to use it from Linux side.
I'm away from my linux laptop, so could you help to:

1. applying the patches.
2. modifying the following line in drivers/acpi/bus.c from:
       status = acpi_initialize_objects(ACPI_FULL_INITIALIZATION);
   to:
       status = acpi_initialize_objects(ACPI_NO_SYSTEM_SPACES_INIT);
And try again.

Sorry for the mistake.

Thanks
-Lv

Created attachment 212521 [details]
dmesg for comment #39

Better. Two errors are eliminated.

Thanks for the test!

This is the last one:
[    0.390782] ACPI Error: No handler for Region [RAM_] (ffff8801593d32d0) [EmbeddedControl] (20160318/evregion-192)
[    0.390792] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160318/exfldio-299)
[    0.390801] ACPI Error: Method parse/execution failed [\_SB.LID0._PSW] (Node ffff8801593d51e0), AE_NOT_EXIST (20160318/psparse-542)
It doesn't seem to be related to the intialization order issues.

Thus we haven't done any debugging or fixing against this error entry.
Let me consider what's happening there.
If I cannot figure it out, I may ask you to test again with a new debugging patch.

Thanks and best regards
-Lv

Created attachment 212581 [details]
[PATCH] ACPICA: Events: Add a new initialization flag to bypass system_memory/system_io operation region initialization

I updated attachment 212341 [details] in order to complete it for our bug fix.
Then I noticed issues in it when I unit tested it.
Please confirm the fix again and upload the boot log using this new patch.

The following patches have been accepted by an upstream repo:
   https://patchwork.kernel.org/patch/8656631/
   https://patchwork.kernel.org/patch/8656681/
   https://patchwork.kernel.org/patch/8656691/
   https://patchwork.kernel.org/patch/8656671/

So you can use the updated following repo without the need to apply the above 4 patches:
   # git clone git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
   # git checkout bleeding-edge

Thanks and best regards
-Lv

I think I now know the cause of the last issue. Let me summerize.

I noticed 3 issues from this bug report:
1. ECDT support was wrong
   This has been fixed by the following patches and they are now in linux-pm.git.
   https://patchwork.kernel.org/patch/8656631/
   https://patchwork.kernel.org/patch/8656681/
   https://patchwork.kernel.org/patch/8656691/
   https://patchwork.kernel.org/patch/8656671/
2. _REG shouldn't be executed for SystemMemory/SystemIo
   This has been fixed by attachment 212581 [details].
   Though I've worked it around in ACPICA, TBH, this is in fact a Linux ACPI specific issue.
   Linux shouldn't invoke device enumeration stuffs implemented in ACPICA.
   Invoking ACPICA device enumeration can mess up BIOS expected initialization order.
   Linux should evaluate _STA/_REG/_CBA/_INI in the device enumeration process itself (acpi_bus_scan()).
   This can also help to eliminate number of namespace walks and tune the boot sequence faster.
3. EC driver enumeration order was wrong
   For the last error, it looks to me like:
   Linux should have EC address space handler ready before performing ACPI bus scan.
   Since this is a Linux ACPI specific issue rather than an ACPICA issue, and I'm not the right person to fix any ACPI enumeration bug, I wonder if anyone owning that will be intrested in solving this issue.
   While I have more urgent ACPICA stuffs pending.
   Thus let's wait a while to see if there's anyone going to fix the last issue for us.

Thanks and best regards
-Lv

Created attachment 212641 [details]
dmesg for comment #42

Same as previous.

(In reply to Nicholas from comment #44)
> Created attachment 212641 [details]
> dmesg for comment #42
> 
> Same as previous.

Good!
Let me wait a while to see if anyone from my team is interested in fixing the 3rd bug.

Thanks and best regards
-Lv

If BIOS wants EC accesses in the device enumeration process, it should provide ECDT.
While for this case, _PSW doesn't seem to be a control method that will be executed during device enumeration.
So this still looks like a bug in Linux ACPI.

Thanks
-Lv

I saw _PSW was invoked from drivers/acpi/scan.c in acpi_bus_get_wakeup_device_flags().
So making a proper fix requires more information than the ACPI specification can give us.

We need to probe windows behavior to see how this is invoked by the de-facto standard implementation:
1. Whether _PSW is invoked from the same namespace walk or from the different namespace walk than _INI.
2. Whether EC._REG is invoked before _PSW or invoked after _PSW.

Thanks
-Lv

Can you confirm if the last issue can be fixed by attachment 218601 [details].

Thanks
-Lv

Created attachment 218991 [details]
dmesg for comment #48

Comment on attachment 218991 [details]
dmesg for comment #48

Lv, with the last patch and 4.7.0-rc1test kernel from rafael/linux-pm.git I have more acpi errors then before.

(In reply to Nicholas from comment #50)
> Comment on attachment 218991 [details]
> dmesg for comment #48
> 
> Lv, with the last patch and 4.7.0-rc1test kernel from rafael/linux-pm.git I
> have more acpi errors then before.

You needn't worry about this.
This is just because, the attachment 212521 [details] hasn't been upstreamed.
I probed windows behavior for this patch, and it probably should be re-worked.

For now, you can apply both attachment 212521 [details] and attachment 218601 [details] for your test.

Thanks
-Lv

I think you can:
1. clone rafael/linux-pm.git, checkout linux-next.
2. apply the attachment 212581 [details] and the attachment 218601 [details].
3. try again.

If you can still see errors.
Please boot the kernel with (need CONFIG_ACPI_DEBUG=y):
acpi.trace_state=method acpi.trace_method_name=_SB.PCI0.LPCB.EC0._REG
And upload the log here.

Thanks and best regards
-Lv

Created attachment 221221 [details]
dmesg for comment #52 with debug

Hi Lv,

Seems that 4.7.0-rc4 has been applied lv-ec1.patch.

Have two errors, run with the specified debug directive, dmesg is attached.

Thanks for the test.
This looks like a new order issue.

When \_SB.PCI0.LPCB.EC0._REG(EmbeddedControl, DISCONNECT) is executed, ACPICA has already removed the EmbeddedControl's operation region handler:
1. remove handler
2. execute _REG

The correct order should be:
1. execute _REG
2. remove handler

I'll work out a fix for this.

Thanks and best regards
-Lv

Created attachment 222301 [details]
[PATCH] ACPI / EC: Fix an order issue in ec_remove_handlers()

Please apply this patch and try again.

Thanks
-Lv

Created attachment 222311 [details]
[PATCH v2] ACPI / EC: Fix an order issue in ec_remove_handlers()

I just reproduced the issue by customizing tables.
And found the previous wasn't correct.

Please use the updated v2 patch.

Thanks
-Lv

Someone in the community has tested this patch.
So let me mark it as "Resolved".

Thanks
-Lv

Hi Lv,

I tested today with linux-pm.git bleeding-edge branch. The patch from comment #56 already was applied. I had errors without patch from attachment #212581 [details] and did not have errors with that patch.

Thanks

Closing...
I'll keep my eyes on a refined version of attachment 212581 [details] in ACPICA upstream.

Thanks

Filed an ACPICA bug to track the last patch:
http://bugs.acpica.org/show_bug.cgi?id=1339

I'll close this bug.

*** Bug 192501 has been marked as a duplicate of this bug. ***