acpi_resource bug?

I'm not very familiar with the acpi code, but we have seen an
intermittent issue on boot:

Panic occurred in module kernel loaded at 0xffffffff80100000:

Stack: --------------------------------------------------
kernel:trap_fatal+0xac
kernel:trap_pfault+0x24c
kernel:trap+0x42e
kernel:bcopy+0x16
kernel:AcpiWalkResources+0xdf
kernel:acpi_lookup_irq_resource+0x9e
kernel:acpi_alloc_resource+0x249
kernel:bus_alloc_resource+0x97
kernel:sioattach+0x446
kernel:device_attach+0x63
kernel:bus_generic_attach+0x27
kernel:acpi_probe_children+0x50
kernel:acpi_attach+0x836
kernel:device_attach+0x63
kernel:bus_generic_attach+0x27
kernel:nexus_attach+0x25
kernel:device_attach+0x63
kernel:root_bus_configure+0x2d
kernel:configure+0x1a
kernel:mi_startup+0x64
--------------------------------------------------
cpuid = 0; apic id = 00
fault virtual address   = 0xffffff8003abe000
fault code              = supervisor read data, page not present

acpi_lookup_irq_handler() is trying to bcopy an entire ACPI_RESOURCE
(68 bytes) from the input pointer, even though in this case the
resource was a ACPI_RESOURCE_TYPE_IRQ (5 bytes), and the loop in
AcpiWalkResourcessaw is seeing res->Length == 0x10.

In this case, I found the following resouces on the list:

(gdb) x/2wx  0xffffff8003abdfb0
0xffffff8003abdfb0:     0x00000004      0x00000010
(gdb) x/2wx  0xffffff8003abdfc0
0xffffff8003abdfc0:     0x00000004      0x00000010
(gdb) x/2wx  0xffffff8003abdfd0
0xffffff8003abdfd0:     0x00000000      0x00000010
(gdb) x/2wx  0xffffff8003abdfe0
0xffffff8003abdfe0:     0x00000001      0x00000010
(gdb) x/2wx  0xffffff8003abdff0
0xffffff8003abdff0:     0x00000007      0x00000010

So copying 68 bytes from 0xffffff8003abdfd0 will always fault.

What I wonder is the following:

1) should the length of the bcopy() be changed to either respect
res->Length or the actual length of the ACPI_RESOURCE_DATA for the
type?

2) why would there be no memory mapped at the next virtual page on
some boots, but not others?  I *think* that a reboot doesn't clear the
issue, but booting into a different kernel with no relevant changes
will change whether the panic on boot is hit.

Thanks,
matthew