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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 29 Mar 2014 11:19:03 -0600
From:	Bjorn Helgaas <>
To:	Linus Torvalds <>
Cc:	Yinghai Lu <>,
	Parag Warudkar <>,
	LKML <>,
	"Rafael J. Wysocki" <>,,
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 <> 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_execute(acpi_device_hotplug, ...)
	    acpi_pci_root_scan_dependent        # .hotplug.scan_dependent
		      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

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 as a place to archive
your logs.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists