lkml.org 
[lkml]   [2014]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: BAR 14: can't assign mem (size 0x200000)
    [+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


    \
     
     \ /
      Last update: 2014-03-29 18:41    [W:3.112 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site