On Tue, Mar 24, 2015 at 5:27 PM, Michael D Labriola <mlabriol@xxxxxxxx> wrote: > Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote on 03/24/2015 01:27:02 PM: >> Thanks for the report, Michael, and sorry for the inconvenience. I > think >> the patch below will fix it, but I don't think it's the right fix either >> because it seems a little ad hoc to sprinkle "acpi_pci_disabled" tests >> around like fairy dust. I wonder if we can set things up so ACPI > methods >> would fail gracefully like they do when ACPI is disabled at > compile-time. >> >> I can boot with "acpi=off" on qemu just fine, and when we look up the > ACPI >> device handles, we just get NULL pointers, so everything works out even >> without a fix like the one below. > > FYI, I'm not passing "acpi=off" on the guest's command line... I believe > it's getting turned off dynamically by the guest kernel. I get the > following in dmesg within the 1st dozen lines: > > ACPI in unprivileged domain disabled That's from xen_arch_setup(), which prints it when it calls disable_acpi(). Booting with "acpi=off" also calls disable_acpi(), so the effect should be similar. But of course xen's PCI enumeration is started a little differently and my guess is that difference is what leads to this oops. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html