On Fri, 14 Oct 2016, Ilya Kaliman wrote: > dmesg: > OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016 > i...@puffy.my.domain:/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