Mailing List Archive

On Fri, Mar 28, 2014 at 5:40 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
> No issues with fresh boot, however after resume from suspend I see
> these messages -
>
> [11548.934625] pci_bus 0000:03: Allocating resources
> [11548.934645] pci 0000:02:00.0: bridge window [io 0x1000-0x0fff] to
> [bus 03] add_size 1000
> [11548.934648] pci 0000:02:00.0: bridge window [mem
> 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
> [11548.934650] pci 0000:02:00.0: bridge window [mem
> 0x00100000-0x000fffff] to [bus 03] add_size 200000
> [11548.934653] pci 0000:02:00.0: res[14]=[mem 0x00100000-0x000fffff]
> get_res_add_size add_size 200000
> [11548.934655] pci 0000:02:00.0: res[15]=[mem 0x00100000-0x000fffff
> 64bit pref] get_res_add_size add_size 200000
> [11548.934656] pci 0000:02:00.0: res[13]=[io 0x1000-0x0fff]
> get_res_add_size add_size 1000
> [11548.934659] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
> [11548.934661] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
> [11548.934662] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
> [11548.934664] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
> [11548.934666] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
> [11548.934667] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
> [11548.934669] pci 0000:02:00.0: PCI bridge to [bus 03]
> [11548.934697] pci 0000:02:00.0: no hotplug settings from platform
> [11548.934698] pci 0000:02:00.0: using default PCI settings
>

>
> I am running Ubuntu daily mainline build from couple days ago - I
> think it should include the above commit.
>
> Let me know if more info is needed - I don't see any issues because of
> these but that may be because I am not using VTd for anything.

Can you send out whole boot log (include init booting and from resume) and
lspci -tv and lspci -vvxxxx ?

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, Mar 28, 2014 at 9:16 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Mar 28, 2014 at 5:40 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
>> No issues with fresh boot, however after resume from suspend I see
>> these messages -
>>
>> [11548.934625] pci_bus 0000:03: Allocating resources
>> [11548.934645] pci 0000:02:00.0: bridge window [io 0x1000-0x0fff] to
>> [bus 03] add_size 1000
>> [11548.934648] pci 0000:02:00.0: bridge window [mem
>> 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
>> [11548.934650] pci 0000:02:00.0: bridge window [mem
>> 0x00100000-0x000fffff] to [bus 03] add_size 200000
>> [11548.934653] pci 0000:02:00.0: res[14]=[mem 0x00100000-0x000fffff]
>> get_res_add_size add_size 200000
>> [11548.934655] pci 0000:02:00.0: res[15]=[mem 0x00100000-0x000fffff
>> 64bit pref] get_res_add_size add_size 200000
>> [11548.934656] pci 0000:02:00.0: res[13]=[io 0x1000-0x0fff]
>> get_res_add_size add_size 1000
>> [11548.934659] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
>> [11548.934661] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
>> [11548.934662] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
>> [11548.934664] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
>> [11548.934666] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
>> [11548.934667] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
>> [11548.934669] pci 0000:02:00.0: PCI bridge to [bus 03]
>> [11548.934697] pci 0000:02:00.0: no hotplug settings from platform
>> [11548.934698] pci 0000:02:00.0: using default PCI settings
>>
>

> Can you send out whole boot log (include init booting and from resume) and
> lspci -tv and lspci -vvxxxx ?

lspci -tv
-----------
~# lspci -tv
-[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller
+-02.0 Intel Corporation Xeon E3-1200 v3 Processor
Integrated Graphics Controller
+-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller
+-14.0 Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI
+-16.0 Intel Corporation 8 Series/C220 Series Chipset
Family MEI Controller #1
+-16.3 Intel Corporation 8 Series/C220 Series Chipset
Family KT Controller
+-19.0 Intel Corporation Ethernet Connection I217-LM
+-1a.0 Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2
+-1b.0 Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller
+-1c.0-[01]--
+-1c.3-[02-03]----00.0-[03]--
+-1c.4-[04-3c]--
+-1d.0 Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1
+-1f.0 Intel Corporation C226 Series Chipset Family Server
Advanced SKU LPC Controller
+-1f.2 Intel Corporation 8 Series/C220 Series Chipset
Family 6-port SATA Controller 1 [AHCI mode]
\-1f.3 Intel Corporation 8 Series/C220 Series Chipset
Family SMBus Controller

lspci -vvxxxx and dmesg output are kind of big, so attached.

Parag

On Fri, Mar 28, 2014 at 6:55 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
>> Can you send out whole boot log (include init booting and from resume) and
>> lspci -tv and lspci -vvxxxx ?
>
> lspci -tv
> -----------
> ~# lspci -tv
> -[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller
> +-02.0 Intel Corporation Xeon E3-1200 v3 Processor
> Integrated Graphics Controller
> +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor HD Audio Controller
> +-14.0 Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI
> +-16.0 Intel Corporation 8 Series/C220 Series Chipset
> Family MEI Controller #1
> +-16.3 Intel Corporation 8 Series/C220 Series Chipset
> Family KT Controller
> +-19.0 Intel Corporation Ethernet Connection I217-LM
> +-1a.0 Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #2
> +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High
> Definition Audio Controller
> +-1c.0-[01]--
> +-1c.3-[02-03]----00.0-[03]--
> +-1c.4-[04-3c]--
> +-1d.0 Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #1
> +-1f.0 Intel Corporation C226 Series Chipset Family Server
> Advanced SKU LPC Controller
> +-1f.2 Intel Corporation 8 Series/C220 Series Chipset
> Family 6-port SATA Controller 1 [AHCI mode]
> \-1f.3 Intel Corporation 8 Series/C220 Series Chipset
> Family SMBus Controller
>
> lspci -vvxxxx and dmesg output are kind of big, so attached.

Hi, Parag,

For the boot path, kernel is right.
BIOS does not assign resource for
00:1c.0, (io, mmio, mmio pref), 00:1c.3(io, mmio, mmio pref), 00:1c.4 (io).

but 00:1c.0 00:1c.4 support hotplug either in acpiphp or pcie slot cap.

[ 0.263398] acpiphp: Slot [1] registered
[ 0.263405] pci 0000:00:1c.0: PCI bridge to [bus 01]
[ 0.263884] acpiphp: Slot [1-1] registered
[ 0.263891] pci 0000:00:1c.4: PCI bridge to [bus 04-3c]

so kernel assign new resource to them.

[ 0.281764] pci 0000:00:1c.0: BAR 14: assigned [mem 0x9f200000-0x9f3fffff]
[ 0.281768] pci 0000:00:1c.0: BAR 15: assigned [mem
0x9f400000-0x9f5fffff 64bit pref]
[ 0.281770] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff]
[ 0.281771] pci 0000:00:1c.4: BAR 13: assigned [io 0x3000-0x3fff]

but 00:1c.3 ==> 02:00.0 (bus 03) does not support hotplug.
so kernel does not assign resource 00:1c.3.

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).

so you will have

[11548.934659] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
[11548.934661] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
[11548.934662] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
[11548.934664] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
[11548.934666] pci 0000:02:00.0: BAR 15: can't assign mem pref (size 0x200000)
[11548.934667] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Mar 29, 2014 at 3:11 AM, Yinghai Lu <yinghai@kernel.org> wrote:
>
> For the boot path, kernel is right.
> BIOS does not assign resource for
> 00:1c.0, (io, mmio, mmio pref), 00:1c.3(io, mmio, mmio pref), 00:1c.4 (io).
>
> but 00:1c.0 00:1c.4 support hotplug either in acpiphp or pcie slot cap.
>
> [ 0.263398] acpiphp: Slot [1] registered
> [ 0.263405] pci 0000:00:1c.0: PCI bridge to [bus 01]
> [ 0.263884] acpiphp: Slot [1-1] registered
> [ 0.263891] pci 0000:00:1c.4: PCI bridge to [bus 04-3c]
>
> so kernel assign new resource to them.
>
> [ 0.281764] pci 0000:00:1c.0: BAR 14: assigned [mem 0x9f200000-0x9f3fffff]
> [ 0.281768] pci 0000:00:1c.0: BAR 15: assigned [mem
> 0x9f400000-0x9f5fffff 64bit pref]
> [ 0.281770] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff]
> [ 0.281771] pci 0000:00:1c.4: BAR 13: assigned [io 0x3000-0x3fff]

OK. I got that part.

> but 00:1c.3 ==> 02:00.0 (bus 03) does not support hotplug.
> so kernel does not assign resource 00:1c.3.
>
> 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).
>
Why are things different at resume time though? Is there a fix here -
to detect at resume time that parent bridge for 02:00.0 has no
resources and to skip trying to assign resources to it?
Or is it that pci_configure_slot should not be called at resume time
and that's what is causing this message?

Thanks for taking a look at this.

Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[+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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Mar 29, 2014 at 1:19 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+cc Rafael, linux-pci, linux-acpi]
>
> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:

>> 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?

I have attached a single acpidump to the bugzilla.

I realized that I misspoke when I said VTd makes a difference.
Actually on 3.14 exact same message appears on resume irrespective of
whether or not VTd is enabled.

However on 3.11 (3.11.0-18-generic Ubuntu LTS latest kernel) - I don't
see those messages irrespective of VTd status.
I must have accidentally booted into 3.11 kernel after disabling VTd
and thought the messages went away because of disabling VTd.

So we can ignore the VTd part.

>
> 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.

Not sure if Ubuntu includes any patches on top of 3.11 mainline that
make a difference to this issue - but in case they don't this might be
a regression.
About the seriousness part - I am not seeing any issues in my regular
use. Not sure what that bridge does and if there are any specific
devices involved - so it might just be that I am not using anything
that could be problematic due to this issue.

Thanks,

Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
>> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:
>
>>> Parag, can you add a WARN_ON_ONCE() to that message, so that we see
>>> what the call chain is for it.

Parag, did you ever try this?

> ...
> Not sure if Ubuntu includes any patches on top of 3.11 mainline that
> make a difference to this issue - but in case they don't this might be
> a regression.

I doubt that Ubuntu includes any patches relevant to this issue.

Even though it doesn't seem to cause any problems, we're going to get
a lot of complaints about these scary-looking messages when resuming,
so I think we should figure this out and fix it.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 10 Apr 2014, Bjorn Helgaas wrote:

> On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
> >> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:
> >
> >>> Parag, can you add a WARN_ON_ONCE() to that message, so that we see
> >>> what the call chain is for it.
>
> Parag, did you ever try this?

No I haven't so far - I assumed the call chain you posted initially was
the only possibility. I will give it a try.

> I doubt that Ubuntu includes any patches relevant to this issue.
>
> Even though it doesn't seem to cause any problems, we're going to get
> a lot of complaints about these scary-looking messages when resuming,
> so I think we should figure this out and fix it.

Sure, since the resource assignments aren't an issue during fresh boot, it
might just be something worth fixing in the resume path.

Thanks,
Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 10 Apr 2014, Bjorn Helgaas wrote:

> On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar <parag.lkml@gmail.com> wrote:
> >> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:
> >
> >>> Parag, can you add a WARN_ON_ONCE() to that message, so that we see
> >>> what the call chain is for it.
>
> Parag, did you ever try this?
>

Below is the output of WARN_ON_ONCE(1) in drivers/pci/setup-res.c.

Parag

[ 339.142257] ACPI: \_SB_.PCI0.RP01: Bus check in hotplug_event()
[ 339.142293] ACPI: \_SB_.PCI0.RP04: Bus check in hotplug_event()
[ 339.142420] pci_bus 0000:03: Allocating resources
[ 339.142437] pci 0000:02:00.0: bridge window [io 0x1000-0x0fff] to [bus
03] add_size 1000
[ 339.142443] pci 0000:02:00.0: bridge window [mem 0x00100000-0x000fffff
64bit pref] to [bus 03] add_size 200000
[ 339.142448] pci 0000:02:00.0: bridge window [mem 0x00100000-0x000fffff]
to [bus 03] add_size 200000
[ 339.142454] pci 0000:02:00.0: res[14]=[mem 0x00100000-0x000fffff]
get_res_add_size add_size 200000
[ 339.142456] pci 0000:02:00.0: res[15]=[mem 0x00100000-0x000fffff 64bit
pref] get_res_add_size add_size 200000
[ 339.142457] pci 0000:02:00.0: res[13]=[io 0x1000-0x0fff]
get_res_add_size add_size 1000
[ 339.142459] ------------[ cut here ]------------
[ 339.142467] WARNING: CPU: 7 PID: 4071 at drivers/pci/setup-res.c:255
_pci_assign_resource+0x1a0/0x1c0()
[ 339.142471] Modules linked in: xt_TCPMSS cuse ipt_MASQUERADE
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables
x_tables bridge stp llc snd_hda_codec_realtek snd_hda_codec_hdmi
snd_hda_codec_generic rfcomm bnep bluetooth binfmt_misc i915 joydev
x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_intel kvm
snd_hda_controller snd_hda_codec hid_logitech_dj usbhid snd_hwdep hid
nls_iso8859_1 snd_pcm video drm_kms_helper snd_seq_midi snd_seq_midi_event
drm snd_rawmidi crct10dif_pclmul crc32_pclmul hp_wmi sparse_keymap
ghash_clmulni_intel ppdev snd_seq aesni_intel aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd snd_seq_device psmouse snd_timer snd
microcode mei_me serio_raw wmi mei lpc_ich parport_pc soundcore
i2c_algo_bit tpm_infineon mac_hid coretemp lp parport e1000e ptp ahci
pps_core libahci
[ 339.142976] CPU: 7 PID: 4071 Comm: kworker/u16:2 Tainted: G W
3.14.0+ #4
[ 339.142978] Hardware name: Hewlett-Packard HP Z230 Tower
Workstation/1905, BIOS L51 v01.18 01/23/2014
[ 339.142981] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 339.142983] 0000000000000009 ffff88044378bac0 ffffffff81717fb4
0000000000000000
[ 339.142985] ffff88044378baf8 ffffffff8106534d ffff8804451a8658
000000009f200000
[ 339.142987] ffff8804451a8000 ffff880445553400 0000000000001000
ffff88044378bb08
[ 339.142989] Call Trace:
[ 339.142994] [<ffffffff81717fb4>] dump_stack+0x45/0x56
[ 339.142997] [<ffffffff8106534d>] warn_slowpath_common+0x7d/0xa0
[ 339.142999] [<ffffffff8106542a>] warn_slowpath_null+0x1a/0x20
[ 339.143002] [<ffffffff813a1280>] _pci_assign_resource+0x1a0/0x1c0
[ 339.143005] [<ffffffff815fa1d0>] ? powercap_register_zone+0x650/0x650
[ 339.143007] [<ffffffff813a15ec>] pci_assign_resource+0xac/0x240
[ 339.143012] [<ffffffff814810fd>] ? dev_printk+0x4d/0x50
[ 339.143014] [<ffffffff813a251c>]
assign_requested_resources_sorted+0x6c/0xd0
[ 339.143017] [<ffffffff813a27f2>] __assign_resources_sorted+0x272/0x450
[ 339.143019] [<ffffffff813a2bc5>] ? __dev_sort_resources+0x1f5/0x270
[ 339.143023] [<ffffffff8170c0e1>] __pci_bus_assign_resources+0x61/0x110
[ 339.143025] [<ffffffff8170c5c4>] enable_slot+0x164/0x300
[ 339.143030] [<ffffffff8148e67c>] ? __pm_runtime_resume+0x5c/0x80
[ 339.143033] [<ffffffff813b55e8>] acpiphp_check_bridge.part.7+0xc8/0xf0
[ 339.143035] [<ffffffff813b5ec0>] acpiphp_hotplug_notify+0x170/0x1f0
[ 339.143037] [<ffffffff813b5d50>] ? acpiphp_post_dock_fixup+0xc0/0xc0
[ 339.143040] [<ffffffff813e1a09>] acpi_device_hotplug+0x3a0/0x3ed
[ 339.143042] [<ffffffff813dbbb0>] acpi_hotplug_work_fn+0x1e/0x29
[ 339.143047] [<ffffffff81080cf2>] process_one_work+0x182/0x450
[ 339.143049] [<ffffffff81081ab1>] worker_thread+0x121/0x410
[ 339.143051] [<ffffffff81081990>] ? rescuer_thread+0x3e0/0x3e0
[ 339.143053] [<ffffffff81088372>] kthread+0xd2/0xf0
[ 339.143055] [<ffffffff810882a0>] ? kthread_create_on_node+0x190/0x190
[ 339.143058] [<ffffffff8172903c>] ret_from_fork+0x7c/0xb0
[ 339.143060] [<ffffffff810882a0>] ? kthread_create_on_node+0x190/0x190
[ 339.143061] ---[ end trace d0c4e4d8d8734d92 ]---
[ 339.143064] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
[ 339.143066] pci 0000:02:00.0: BAR 15: can't assign mem pref (size
0x200000)
[ 339.143068] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
[ 339.143070] pci 0000:02:00.0: BAR 14: can't assign mem (size 0x200000)
[ 339.143072] pci 0000:02:00.0: BAR 15: can't assign mem pref (size
0x200000)
[ 339.143073] pci 0000:02:00.0: BAR 13: can't assign io (size 0x1000)
[ 339.143075] pci 0000:02:00.0: PCI bridge to [bus 03]
[ 339.143104] pci 0000:02:00.0: no hotplug settings from platform
[ 339.143105] pci 0000:02:00.0: using default PCI settings
[ 339.143128] ACPI: \_SB_.PCI0.RP05: Bus check in hotplug_event()
[ 339.143300] done.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/