lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 29 Mar 2014 11:19:03 -0600 From: Bjorn Helgaas <bhelgaas@...gle.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Yinghai Lu <yinghai@...nel.org>, Parag Warudkar <parag.lkml@...il.com>, LKML <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org Subject: Re: 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@...nel.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists