On Mar 13, 2012, at 5:18 PM, Sarah Sharp wrote: > Hi Tom, > > I'm the driver xHCI maintainer, and it helps if you Cc me on mail about > USB 3.0. Otherwise it gets lost in the noise. :) Thanks for the reply Sarah. > > On Mon, Mar 12, 2012 at 01:23:41PM +0000, Tom Goetz wrote: >> I have two machines where the Intel xHCI devices don't wake up from runtime >> suspend after a S3 suspend/resume on Xen 4.0.3 and Linux 3.2.9. > > So the system wakes up from S3, but the host doesn't report any port > status changes when you plug in a USB device? I've narrowed it down farther since then. Anytime you set the runtime power mode to "auto" and let the device go into D3 after a S3 resume, plugging in a device will not wake the xHCI HCD driver. Here's a trace of the path that wakes the device in the good case, but fails to happen in bad case: [ 612.701424] usb_hcd_resume_root_hub[2079] xHCI Host Controller [ 612.701431] ------------[ cut here ]------------ [ 612.701444] WARNING: at /home/likewise-open/ORC/tgoetz/sandbox/orc-precise/linux-3.2/drivers/usb/core/hcd.c:2080 usb_hcd_resume_root_hub+0x4f/0xa0() [ 612.701454] Modules linked in: e1000e iwlwifi(O) mac80211(O) cfg80211(O) xhci_hcd tpm_tis tpm_infineon tpm tpm_bios ehci_hcd xt_mac xt_tcpudp ipt_MASQUERADE xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables iscsi_scst(O) scst_vdisk(O) crc32c libcrc32c scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi snd_hda_codec_hdmi snd_hda_codec_idt arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm hp_wmi sparse_keymap snd_timer ppdev parport_pc psmouse snd soundcore serio_raw snd_page_alloc parport zram(C) ahci libahci sdhci_pci sdhci i915 drm_kms_helper drm i2c_algo_bit video intel_agp intel_gtt [last unloaded: tpm_bios] [ 612.701557] Pid: 0, comm: swapper/0 Tainted: G WC O 3.2.9-orc #28 [ 612.701559] Call Trace: [ 612.701560] <IRQ> [<ffffffff810633df>] warn_slowpath_common+0x7f/0xc0 [ 612.701566] [<ffffffff8106343a>] warn_slowpath_null+0x1a/0x20 [ 612.701569] [<ffffffff8141933f>]usb_hcd_resume_root_hub+0x4f/0xa0 [ 612.701573] [<ffffffffa049a52a>] xhci_irq+0xb0a/0x11c0 [xhci_hcd] [ 612.701576] [<ffffffff8104b853>] ? __wake_up+0x53/0x70 [ 612.701579] [<ffffffff8100a58d>] ? xen_force_evtchn_callback+0xd/0x10 [ 612.701582] [<ffffffff8100ad42>] ? check_events+0x12/0x20 [ 612.701585] [<ffffffffa049ac11>]xhci_msi_irq+0x31/0x40 [xhci_hcd] [ 612.701589] [<ffffffff810d0b15>] handle_irq_event_percpu+0x55/0x220 [ 612.701592] [<ffffffff812b651b>] ? radix_tree_lookup+0xb/0x10 [ 612.701595] [<ffffffff810d0d2e>] handle_irq_event+0x4e/0x80 [ 612.701598] [<ffffffff810d3d24>] handle_edge_irq+0x84/0x130 [ 612.701602] [<ffffffff813415d9>] __xen_evtchn_do_upcall+0x199/0x250 [ 612.701605] [<ffffffff8134362f>] xen_evtchn_do_upcall+0x2f/0x50 [ 612.701608] [<ffffffff81581efe>] xen_do_hypervisor_callback+0x1e/0x30 [ 612.701609] <EOI> [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [ 612.701615] [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000 [ 612.701618] [<ffffffff8100a4c0>] ? xen_safe_halt+0x10/0x20 [ 612.701621] [<ffffffff8101c653>] ? default_idle+0x53/0x1d0 [ 612.701624] [<ffffffff81013236>] ? cpu_idle+0xd6/0x120 [ 612.701628] [<ffffffff81552f6e>] ? rest_init+0x72/0x74 [ 612.701633] [<ffffffff81accbff>] ? start_kernel+0x3b5/0x3c2 [ 612.701636] [<ffffffff81acc34b>] ? x86_64_start_reservations+0x136/0x13a [ 612.701639] [<ffffffff81acfecc>] ? xen_start_kernel+0x630/0x637 [ 612.701641] ---[ end trace 81e0ca5cff766fb7 ]--- [ 612.701659] hcd_resume_work[2060] xHCI Host Controller [ 612.701662] __pm_runtime_resume[880] usb3 RPM_GET_PUT 1 [ 612.701663] rpm_resume[512] usb3 before > >> The first is a Ivybridge laptop > > You do mean Ivy Bridge and not Sandy Bridge, correct? Yes. I've now confirmed this on an Ivybridge laptop and a Ivybridge SDP desktop. > >> and after resuming on battery, inserting a >> usb device into a port no longer wakes up the xHCI device. Changing the power >> mode from "auto" to "on" fixes it. It is not broken on Ubuntu 12.04 Beta 1 with >> Linux 3.2.0. > > Interesting. I've been receiving several reports about suspend > failures, but none this specific about the kernel version. Thanks for > the clue. > > Do you see messages about root hub power loss after resume on battery, > like these? > > [ 776.123716] xhci_hcd 0000:00:14.0: setting latency timer to 64 > [ 776.123727] usb usb3: root hub lost power or was reset > [ 776.123729] usb usb4: root hub lost power or was reset I'm not seeing these. > > I'm wondering if the host controller is reacting differently based on > whether the laptop is powered off of AC or not. Oliver noted some bugs > in the S4 power loss resume path, so those might be related. What I'm seeing is it doesn't matter what power state your in when you suspend. Battery also only matters for resume in that it causes runtime power management to be allowed for the xHCI device. If you resume in AC, but set the power control for the device to "auto", you will see the same problem. > >> I have also have a Intel SDP desktop where setting the power mode to "auto" on >> the xHCI device does not break device insertion enabling the device on a fresh >> boot, but does break it after a S3 resume. >> >> I have an instrumented kernel and see no rpm_resume for this device int he bad >> case. Wake up works fine for devices plugged into EHCI. >> >> I've also posted this to xen-devel earlier: >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00727.html > > Why were you posting there in particular? You're much more likely to > get your USB questions answered on this mailing list. :) I'm concerned that this may be a bug in the Xen PVOPs MSI code. To that end I've posted updates on xen-devel here: http://lists.xen.org/archives/html/xen-devel/2012-03/msg00904.html http://lists.xen.org/archives/html/xen-devel/2012-03/msg00727.html http://lists.xen.org/archives/html/xen-devel/2012-03/msg00978.html The con to that theory is that EHCI is also a MSI and works. -Tom Goetz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
