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 0x8010:
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 = 0xff8003abe000
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 0xff8003abdfb0
0xff8003abdfb0: 0x0004 0x0010
(gdb) x/2wx 0xff8003abdfc0
0xff8003abdfc0: 0x0004 0x0010
(gdb) x/2wx 0xff8003abdfd0
0xff8003abdfd0: 0x 0x0010
(gdb) x/2wx 0xff8003abdfe0
0xff8003abdfe0: 0x0001 0x0010
(gdb) x/2wx 0xff8003abdff0
0xff8003abdff0: 0x0007 0x0010
So copying 68 bytes from 0xff8003abdfd0 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
