Bug 194917 - Opregion Dependency - ACPI Error: No handler for Region [XOPR]
Summary: Opregion Dependency - ACPI Error: No handler for Region [XOPR]
Status: RESOLVED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Other (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-18 10:22 UTC by tagorereddy
Modified: 2017-07-04 06:40 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.11-rc2
Tree: Mainline
Regression: No


Attachments
DMESG (42.68 KB, text/plain)
2017-03-18 10:22 UTC, tagorereddy
Details
DSDT (1.04 MB, text/plain)
2017-03-18 10:25 UTC, tagorereddy
Details
SSDT (99.84 KB, text/plain)
2017-03-18 10:25 UTC, tagorereddy
Details
DSDT+SSDT[1-7] (1.21 MB, text/plain)
2017-03-20 06:02 UTC, tagorereddy
Details
acpidump(ASCII HEX, not decompiled) (709.86 KB, text/plain)
2017-03-20 06:10 UTC, tagorereddy
Details
DMESG(without bug) (41.91 KB, text/plain)
2017-03-20 07:03 UTC, tagorereddy
Details

Description tagorereddy 2017-03-18 10:22:57 UTC
Created attachment 255329 [details]
DMESG

SoC: Intel Atom x5-Z8300
================
BUG: (Not a regression)
===
[   20.403162] ACPI Error: No handler for Region [XOPR] (ffff8eefb5cde318) [GenericSerialBus] (20160930/evregion-166)
[   20.403330] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20160930/exfldio-299)
[   20.403453] ACPI Error: Method parse/execution failed [\_SB.STR0._TMP] (Node ffff8eefb5d1f668), AE_NOT_EXIST (20160930/psparse-543)
[   20.403626] thermal thermal_zone1: failed to read out thermal zone (-5)

OCCURANCE: Sporadic. (Doesn't occur on few boots)
========
Comment 1 tagorereddy 2017-03-18 10:25:01 UTC
Created attachment 255331 [details]
DSDT
Comment 2 tagorereddy 2017-03-18 10:25:49 UTC
Created attachment 255333 [details]
SSDT
Comment 3 Zhang Rui 2017-03-20 04:32:33 UTC
please attach the full acpidump output
Comment 4 tagorereddy 2017-03-20 06:02:55 UTC
Created attachment 255357 [details]
DSDT+SSDT[1-7]

DSDT, SSDT1 - SSDT7
Comment 5 tagorereddy 2017-03-20 06:10:28 UTC
Created attachment 255359 [details]
acpidump(ASCII HEX, not decompiled)

If needed,
Non-decompiled ACPIDUMP in ASCII HEX format
Comment 6 tagorereddy 2017-03-20 07:03:09 UTC
Created attachment 255361 [details]
DMESG(without bug)

This is the DMESG output from the instance without this bug.

The difference seems to be that I2C7 bus which is managed by PUNIT is initialized before Intel thermal driver. Since thermal driver is itself reliant on I2C7 bus, this could be the case of improper module-loading order.
Comment 7 Lv Zheng 2017-03-23 06:31:15 UTC
OK, I see.
It seems in ACPI address space handler, we should be able to probe another driver.

Let me think about it how this can work.
Thanks for the report.
Comment 8 tagorereddy 2017-03-23 08:28:21 UTC
(In reply to Lv Zheng from comment #7)
> OK, I see.
> It seems in ACPI address space handler, we should be able to probe another
> driver.
> 
> Let me think about it how this can work.
> Thanks for the report.

XOPR is handled exclusively by IEC7 bus. I2C7 bus is controlled through cherrytrail PUNIT semaphore. Also INT3403, a DPTF thermal device is located on I2C7 bus.

At the moment, 'int3403_thermal' module is loading ahead of 'intel-designware-platform' module causing the issue. I've altered the module load order and everything went smoothly.

Thanks,
Tagore
Comment 9 Lv Zheng 2017-03-29 08:13:32 UTC
> At the moment, 'int3403_thermal' module is loading ahead of
> 'intel-designware-platform' module causing the issue. I've altered the module
> load order and everything went smoothly.

This is a kind of way to fix it.

Do we need to, for example, return -EPROBE_DEFER or invoke request_module() in case "No handler for Region" exception is caught by the Linux kernel via ACPICA exception handler.
Comment 10 Zhang Rui 2017-03-29 08:18:19 UTC
I think so.
This is the way GPIO space operation region does today.
Comment 11 Zhang Rui 2017-07-03 07:12:55 UTC
We can not handle this problem as the way of GPIO.
For the GPIO case, driver gets EPROBE_DEFER when requesting GPIO resource.
But in this case, driver is evaluating an ACPI control method.

the root cause of the problem is that _DEP is missing for STR0, as we can see _DEP for STR1 and STR2.

Closed as this problem is caused by buggy firmware.
Comment 12 Zhang Rui 2017-07-03 07:22:53 UTC
However, there are several workarounds for this problem
1. build ACPI battery driver as module and build in I2C driver.
or
2. manually add _DEP for STR0 in ACPI table, and rebuilt the kernel with customized DSDT.
Comment 13 Lv Zheng 2017-07-04 00:45:17 UTC
Let me re-open it.
Possibly we can just return some significant error number for handler missing.
When such a specific error gets seen by the caller, the caller can return EPROBE_DEFER (if it's really in the .probe call).
Comment 14 Zhang Rui 2017-07-04 03:05:03 UTC
First of all, I'd say this is a FIRMWARE Bug, because everything will work well if  _DEP is added for STR0, in ACPI table.

Second, for the solution described in comment #13, technically, yes, but practically, probably no. We need to kick off the discussion to see if this is the right way to go.

However, for this particular bug, I'd say it should be closed because of buggy firmware. If needed, I can attach a customized DSDT file for the bug reporter to workaround the problem.
Comment 15 Lv Zheng 2017-07-04 06:40:38 UTC
By defining a bug as a firmware bug, we should validate if Windows is also misbehaving to such firmware.

Note You need to log in before you can comment on or make changes to this bug.