Re: BAR 14: can't assign mem (size 0x200000)
On Thu, 10 Apr 2014, Bjorn Helgaas wrote: > On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar 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 :03: Allocating resources [ 339.142437] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [ 339.142443] pci :02:00.0: bridge window [mem 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 [ 339.142448] pci :02:00.0: bridge window [mem 0x0010-0x000f] to [bus 03] add_size 20 [ 339.142454] pci :02:00.0: res[14]=[mem 0x0010-0x000f] get_res_add_size add_size 20 [ 339.142456] pci :02:00.0: res[15]=[mem 0x0010-0x000f 64bit pref] get_res_add_size add_size 20 [ 339.142457] pci :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: GW 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] 0009 88044378bac0 81717fb4 [ 339.142985] 88044378baf8 8106534d 8804451a8658 9f20 [ 339.142987] 8804451a8000 880445553400 1000 88044378bb08 [ 339.142989] Call Trace: [ 339.142994] [] dump_stack+0x45/0x56 [ 339.142997] [] warn_slowpath_common+0x7d/0xa0 [ 339.142999] [] warn_slowpath_null+0x1a/0x20 [ 339.143002] [] _pci_assign_resource+0x1a0/0x1c0 [ 339.143005] [] ? powercap_register_zone+0x650/0x650 [ 339.143007] [] pci_assign_resource+0xac/0x240 [ 339.143012] [] ? dev_printk+0x4d/0x50 [ 339.143014] [] assign_requested_resources_sorted+0x6c/0xd0 [ 339.143017] [] __assign_resources_sorted+0x272/0x450 [ 339.143019] [] ? __dev_sort_resources+0x1f5/0x270 [ 339.143023] [] __pci_bus_assign_resources+0x61/0x110 [ 339.143025] [] enable_slot+0x164/0x300 [ 339.143030] [] ? __pm_runtime_resume+0x5c/0x80 [ 339.143033] [] acpiphp_check_bridge.part.7+0xc8/0xf0 [ 339.143035] [] acpiphp_hotplug_notify+0x170/0x1f0 [ 339.143037] [] ? acpiphp_post_dock_fixup+0xc0/0xc0 [ 339.143040] [] acpi_device_hotplug+0x3a0/0x3ed [ 339.143042] [] acpi_hotplug_work_fn+0x1e/0x29 [ 339.143047] [] process_one_work+0x182/0x450 [ 339.143049] [] worker_thread+0x121/0x410 [ 339.143051] [] ? rescuer_thread+0x3e0/0x3e0 [ 339.143053] [] kthread+0xd2/0xf0 [ 339.143055] [] ? kthread_create_on_node+0x190/0x190 [ 339.143058] [] ret_from_fork+0x7c/0xb0 [ 339.143060] [] ? 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 0x20) [ 339.143066] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [ 339.143068] pci :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 0x20) [ 339.143072] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [ 339.143073] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [ 339.143075] pci :02:00.0: PCI bridge to [bus 03] [ 339.143104] pci :02:00.0: no hotplug settings from platform [ 339.143105] pci :02:00.0: using default PCI settings [ 339.143128] ACPI: \_SB_.PCI0.RP05: Bus check in hotplug_event() [ 339.143300] done. -- To uns
Re: BAR 14: can't assign mem (size 0x200000)
On Thu, 10 Apr 2014, Bjorn Helgaas wrote: On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar parag.l...@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 :03: Allocating resources [ 339.142437] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [ 339.142443] pci :02:00.0: bridge window [mem 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 [ 339.142448] pci :02:00.0: bridge window [mem 0x0010-0x000f] to [bus 03] add_size 20 [ 339.142454] pci :02:00.0: res[14]=[mem 0x0010-0x000f] get_res_add_size add_size 20 [ 339.142456] pci :02:00.0: res[15]=[mem 0x0010-0x000f 64bit pref] get_res_add_size add_size 20 [ 339.142457] pci :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: GW 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] 0009 88044378bac0 81717fb4 [ 339.142985] 88044378baf8 8106534d 8804451a8658 9f20 [ 339.142987] 8804451a8000 880445553400 1000 88044378bb08 [ 339.142989] Call Trace: [ 339.142994] [81717fb4] dump_stack+0x45/0x56 [ 339.142997] [8106534d] warn_slowpath_common+0x7d/0xa0 [ 339.142999] [8106542a] warn_slowpath_null+0x1a/0x20 [ 339.143002] [813a1280] _pci_assign_resource+0x1a0/0x1c0 [ 339.143005] [815fa1d0] ? powercap_register_zone+0x650/0x650 [ 339.143007] [813a15ec] pci_assign_resource+0xac/0x240 [ 339.143012] [814810fd] ? dev_printk+0x4d/0x50 [ 339.143014] [813a251c] assign_requested_resources_sorted+0x6c/0xd0 [ 339.143017] [813a27f2] __assign_resources_sorted+0x272/0x450 [ 339.143019] [813a2bc5] ? __dev_sort_resources+0x1f5/0x270 [ 339.143023] [8170c0e1] __pci_bus_assign_resources+0x61/0x110 [ 339.143025] [8170c5c4] enable_slot+0x164/0x300 [ 339.143030] [8148e67c] ? __pm_runtime_resume+0x5c/0x80 [ 339.143033] [813b55e8] acpiphp_check_bridge.part.7+0xc8/0xf0 [ 339.143035] [813b5ec0] acpiphp_hotplug_notify+0x170/0x1f0 [ 339.143037] [813b5d50] ? acpiphp_post_dock_fixup+0xc0/0xc0 [ 339.143040] [813e1a09] acpi_device_hotplug+0x3a0/0x3ed [ 339.143042] [813dbbb0] acpi_hotplug_work_fn+0x1e/0x29 [ 339.143047] [81080cf2] process_one_work+0x182/0x450 [ 339.143049] [81081ab1] worker_thread+0x121/0x410 [ 339.143051] [81081990] ? rescuer_thread+0x3e0/0x3e0 [ 339.143053] [81088372] kthread+0xd2/0xf0 [ 339.143055] [810882a0] ? kthread_create_on_node+0x190/0x190 [ 339.143058] [8172903c] ret_from_fork+0x7c/0xb0 [ 339.143060] [810882a0] ? kthread_create_on_node+0x190/0x190 [ 339.143061] ---[ end trace d0c4e4d8d8734d92 ]--- [ 339.143064] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [ 339.143066] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [ 339.143068] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [ 339.143070] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [ 339.143072] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20
Re: BAR 14: can't assign mem (size 0x200000)
On Thu, 10 Apr 2014, Bjorn Helgaas wrote: > On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar parag.l...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Thu, 10 Apr 2014, Bjorn Helgaas wrote: On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar parag.l...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 1:19 PM, Bjorn Helgaas 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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_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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
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. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 3:11 AM, Yinghai Lu 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 :00:1c.0: PCI bridge to [bus 01] > [0.263884] acpiphp: Slot [1-1] registered > [0.263891] pci :00:1c.4: PCI bridge to [bus 04-3c] > > so kernel assign new resource to them. > > [0.281764] pci :00:1c.0: BAR 14: assigned [mem 0x9f20-0x9f3f] > [0.281768] pci :00:1c.0: BAR 15: assigned [mem > 0x9f40-0x9f5f 64bit pref] > [0.281770] pci :00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] > [0.281771] pci :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Fri, Mar 28, 2014 at 6:55 PM, Parag Warudkar wrote: >> Can you send out whole boot log (include init booting and from resume) and >> lspci -tv and lspci -vv ? > > lspci -tv > --- > ~# lspci -tv > -[: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 -vv 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 :00:1c.0: PCI bridge to [bus 01] [0.263884] acpiphp: Slot [1-1] registered [0.263891] pci :00:1c.4: PCI bridge to [bus 04-3c] so kernel assign new resource to them. [0.281764] pci :00:1c.0: BAR 14: assigned [mem 0x9f20-0x9f3f] [0.281768] pci :00:1c.0: BAR 15: assigned [mem 0x9f40-0x9f5f 64bit pref] [0.281770] pci :00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] [0.281771] pci :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 :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934661] pci :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 :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934667] pci :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Fri, Mar 28, 2014 at 6:55 PM, Parag Warudkar parag.l...@gmail.com wrote: Can you send out whole boot log (include init booting and from resume) and lspci -tv and lspci -vv ? lspci -tv --- ~# lspci -tv -[: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 -vv 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 :00:1c.0: PCI bridge to [bus 01] [0.263884] acpiphp: Slot [1-1] registered [0.263891] pci :00:1c.4: PCI bridge to [bus 04-3c] so kernel assign new resource to them. [0.281764] pci :00:1c.0: BAR 14: assigned [mem 0x9f20-0x9f3f] [0.281768] pci :00:1c.0: BAR 15: assigned [mem 0x9f40-0x9f5f 64bit pref] [0.281770] pci :00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] [0.281771] pci :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 :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934661] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934662] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934664] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934667] pci :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 3:11 AM, Yinghai Lu ying...@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 :00:1c.0: PCI bridge to [bus 01] [0.263884] acpiphp: Slot [1-1] registered [0.263891] pci :00:1c.4: PCI bridge to [bus 04-3c] so kernel assign new resource to them. [0.281764] pci :00:1c.0: BAR 14: assigned [mem 0x9f20-0x9f3f] [0.281768] pci :00:1c.0: BAR 15: assigned [mem 0x9f40-0x9f5f 64bit pref] [0.281770] pci :00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] [0.281771] pci :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 12:11 AM, Yinghai Lu ying...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 ying...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Sat, Mar 29, 2014 at 1:19 PM, Bjorn Helgaas bhelg...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Fri, Mar 28, 2014 at 5:40 PM, Parag Warudkar wrote: > No issues with fresh boot, however after resume from suspend I see > these messages - > > [11548.934625] pci_bus :03: Allocating resources > [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to > [bus 03] add_size 1000 > [11548.934648] pci :02:00.0: bridge window [mem > 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 > [11548.934650] pci :02:00.0: bridge window [mem > 0x0010-0x000f] to [bus 03] add_size 20 > [11548.934653] pci :02:00.0: res[14]=[mem 0x0010-0x000f] > get_res_add_size add_size 20 > [11548.934655] pci :02:00.0: res[15]=[mem 0x0010-0x000f > 64bit pref] get_res_add_size add_size 20 > [11548.934656] pci :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 0x20) > [11548.934661] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) > [11548.934662] pci :02:00.0: BAR 13: can't assign io (size 0x1000) > [11548.934664] pci :02:00.0: BAR 14: can't assign mem (size 0x20) > [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) > [11548.934667] pci :02:00.0: BAR 13: can't assign io (size 0x1000) > [11548.934669] pci :02:00.0: PCI bridge to [bus 03] > [11548.934697] pci :02:00.0: no hotplug settings from platform > [11548.934698] pci :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 -vv ? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BAR 14: can't assign mem (size 0x200000)
No issues with fresh boot, however after resume from suspend I see these messages - [11548.934625] pci_bus :03: Allocating resources [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [11548.934648] pci :02:00.0: bridge window [mem 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 [11548.934650] pci :02:00.0: bridge window [mem 0x0010-0x000f] to [bus 03] add_size 20 [11548.934653] pci :02:00.0: res[14]=[mem 0x0010-0x000f] get_res_add_size add_size 20 [11548.934655] pci :02:00.0: res[15]=[mem 0x0010-0x000f 64bit pref] get_res_add_size add_size 20 [11548.934656] pci :02:00.0: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 [11548.934659] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934661] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934662] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934664] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934667] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934669] pci :02:00.0: PCI bridge to [bus 03] [11548.934697] pci :02:00.0: no hotplug settings from platform [11548.934698] pci :02:00.0: using default PCI settings The device in question is - 02:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8893 (rev 52) (prog-if 01 [Subtractive decode]) Physical Slot: 5 Flags: bus master, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 Capabilities: [90] Power Management version 2 Capabilities: [a0] Subsystem: Hewlett-Packard Company Device 1905 After resume the sec-latency is set to 128 instead of 64. This seems to be VTd related - as if I disable VTd in BIOS the message doesn't appear. I saw an older commit which to me looked liked it fixed a similar issue - PCI : Calculate right add_size commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream. During debug of one SRIOV enabled hotplug device, we found found that add_size is not passed properly. 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. Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BAR 14: can't assign mem (size 0x200000)
No issues with fresh boot, however after resume from suspend I see these messages - [11548.934625] pci_bus :03: Allocating resources [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [11548.934648] pci :02:00.0: bridge window [mem 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 [11548.934650] pci :02:00.0: bridge window [mem 0x0010-0x000f] to [bus 03] add_size 20 [11548.934653] pci :02:00.0: res[14]=[mem 0x0010-0x000f] get_res_add_size add_size 20 [11548.934655] pci :02:00.0: res[15]=[mem 0x0010-0x000f 64bit pref] get_res_add_size add_size 20 [11548.934656] pci :02:00.0: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 [11548.934659] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934661] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934662] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934664] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934667] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934669] pci :02:00.0: PCI bridge to [bus 03] [11548.934697] pci :02:00.0: no hotplug settings from platform [11548.934698] pci :02:00.0: using default PCI settings The device in question is - 02:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8893 (rev 52) (prog-if 01 [Subtractive decode]) Physical Slot: 5 Flags: bus master, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 Capabilities: [90] Power Management version 2 Capabilities: [a0] Subsystem: Hewlett-Packard Company Device 1905 After resume the sec-latency is set to 128 instead of 64. This seems to be VTd related - as if I disable VTd in BIOS the message doesn't appear. I saw an older commit which to me looked liked it fixed a similar issue - PCI : Calculate right add_size commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream. During debug of one SRIOV enabled hotplug device, we found found that add_size is not passed properly. 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. Parag -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BAR 14: can't assign mem (size 0x200000)
On Fri, Mar 28, 2014 at 5:40 PM, Parag Warudkar parag.l...@gmail.com wrote: No issues with fresh boot, however after resume from suspend I see these messages - [11548.934625] pci_bus :03: Allocating resources [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [11548.934648] pci :02:00.0: bridge window [mem 0x0010-0x000f 64bit pref] to [bus 03] add_size 20 [11548.934650] pci :02:00.0: bridge window [mem 0x0010-0x000f] to [bus 03] add_size 20 [11548.934653] pci :02:00.0: res[14]=[mem 0x0010-0x000f] get_res_add_size add_size 20 [11548.934655] pci :02:00.0: res[15]=[mem 0x0010-0x000f 64bit pref] get_res_add_size add_size 20 [11548.934656] pci :02:00.0: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 [11548.934659] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934661] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934662] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934664] pci :02:00.0: BAR 14: can't assign mem (size 0x20) [11548.934666] pci :02:00.0: BAR 15: can't assign mem pref (size 0x20) [11548.934667] pci :02:00.0: BAR 13: can't assign io (size 0x1000) [11548.934669] pci :02:00.0: PCI bridge to [bus 03] [11548.934697] pci :02:00.0: no hotplug settings from platform [11548.934698] pci :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 -vv ? Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
