Created attachment 179671 [details]
acpidump from affected system

Hi, I recently updated from 3.10.79 to 3.10.80, and my system wouldn't
boot any more.  I tracked this down to commit 92c934b10ec3 ("ACPI /
init: Fix the ordering of acpi_reserve_resources()").  With that
commit reverted, my system is OK again.

What happens is that ahci fails to initialize because
pcim_iomap_regions_request_all() fails with EBUSY, due to a resource
conflict on the first IO region of the ahci device.  Since my root
device is on ahci, that's the end of that.  I'm sure this is due to a
BIOS / ACPI table bug on my particular platform, but that's scant
comfort when the system won't boot :)

I patched 3.10.80 so that ahci continues to initialize after the
EBUSY, and relevant parts of the kernel log seem to be:

[    3.836643,26] system 00:06: [io  0x0400-0x047f] could not be reserved
...
[    3.844112,26] pci 0000:00:1f.2: BAR 0: assigned [io  0x0410-0x0417]
...
[    6.020040,00] ahci 0000:00:1f.2: BAR 0: can't reserve [io  0x0410-0x0417]

and /proc/ioports shows

    0410-0415 : ACPI CPU throttle

So if I'm understanding properly, for some reason we discover but fail
to reserve the region with the ACPI resources, then PCI decides to
assign ahci IO ports into that range, then ACPI loads and reserves
0x0410-0x0415, and then ahci fails to load.

If I fully revert the patch, then I see

[    3.853857,08] system 00:06: [io  0x0400-0x047f] has been reserved
...
[    3.861806,08] pci 0000:00:1f.2: BAR 0: assigned [io  0x0820-0x0827]

We're able to reserve the range, and then PCI assigns ahci into a
non-conflicting range.

From the link order, drivers/acpi init wll be called before
drivers/pnp init, right?  In my case, the acpi resources ("ACPI
PM1a_EVT_BLK") etc are under a pnp bus.  But if acpi requests the
resources first, then pnp can't request the enclosing range.



Attaching acpidump from the system in question.