Re: BAR 14: can't assign mem (size 0x200000)

[Bjorn Helgaas <bhelgaas@google.com>]

[+cc Rafael, linux-pci, linux-acpi]

On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:
> On Sat, Mar 29, 2014 at 12:11 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> >
> > Later during resuming, kernel try to assign resource 02:00.0 but it will fail
> > as parent bridge 00:1c.3 has no resource.
> > (Not sure how pci_configure_slot get called with this resume path).
> 
> I think that last comment is the most pertinent one: why does resume
> try to assign resources to PCI devices? It should be *restoring* them,
> not re-assigning any resources.
> 
> Parag, can you add a WARN_ON_ONCE() to that message, so that we see
> what the call chain is for it.

I think we likely get a Bus Check notification when resuming, so we're
probably in this path:

    acpi_hotplug_notify_cb
      acpi_hotplug_execute(acpi_device_hotplug, ...)
	acpi_device_hotplug
	  acpi_scan_bus_check
	    acpi_pci_root_scan_dependent        # .hotplug.scan_dependent
	      acpiphp_check_host_bridge
		acpiphp_check_bridge    
		  enable_slot
		    pcibios_resource_survey_bus
		      dev_printk("Allocating resources")

It seems like we ought to do the equivalent of a Bus Check from the
root at boot-time, even if we don't receive an explicit Bus Check
notification then (ACPI 5.0, sec 5.6.6, says "OSPM will typically
perform a full enumeration automatically at boot time, but after
system initialization it is the responsibility of the ACPI AML code to
notify OSPM whenever a re-enumeration operation is required"), but I
don't think we do, which makes the resume path different from the boot
path.

Parag, would you mind collecting an acpidump and attaching it to the
bugzilla below?

Is this a regression?  I guess you said that the message (and the sec-
latency change, which I don't think is applicable to PCIe anyway) are
the only ill effects you see, so it might not be too serious even if
it is.

I am concerned about the VT-d connection and the sec-latency change.
I wouldn't be surprised to find that the resume path doesn't restore
sec-latency, but I don't know why VT-d would affect the resource
allocation.  I guess it's possible that enabling VT-d might change
the ACPI namespace; maybe you could collect *two* acpidumps: one with
VT-d enabled and another with it disabled.

Let's continue the discussion in email, but I did open
https://bugzilla.kernel.org/show_bug.cgi?id=73141 as a place to archive
your logs.

Bjorn