On Fri, 14 Oct 2016, Ilya Kaliman wrote:
> dmesg:
> OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016
> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
..
> acpiec0 at acpi0: Failed to read resource settings
...
> acpidump:
I've taken a brief look at this. The definition of the resources for the
embedded controller is odd:
Scope (_SB.PCI0.LPCB)
{
Device (EC0)
{
Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)
// _HID: Hardware ID
...
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0062, // Range Minimum
0x0062, // Range Maximum
0x00, // Alignment
0x01, // Length
)
IO (Decode16,
0x0066, // Range Minimum
0x0066, // Range Maximum
0x00, // Alignment
0x01, // Length
)
IO (Decode16,
0x0068, // Range Minimum
0x0068, // Range Maximum
0x01, // Alignment
0x08, // Length
)
Memory32Fixed (ReadWrite,
0xFE800E00, // Address Base
0x00010000, // Address Length
)
})
Note that there are *four* resources...but even revision 6.1 of the ACPI
standard only gives meaning for the first *three*, and the third resource
is the GPIO for the SCI interrupt...but is only for hardware-reduced ACPI
platforms, which this machine is not:
...
Use APIC Physical Destination Mode (V4) : 0
Hardware Reduced (V5) : 0
Low Power S0 Idle (V5) : 0
...
So I guess there's two defects in acpicec.c right now:
- we don't use a third resource for the SCI interrupt when hw-reduced
- we barf on extra resources despite vendors deciding to throwing them
in for the hell of it
Perhaps acpiec should use aml_parse_resource() instead of the hand-crafted
parsing it does right now? That would solve the second problem, at
least.
Until we have a better fix, simply deleting the end-of-buffer check as
you've done should have the same end effect, but expect a diff to try out
at some point here...
Philip Guenther
