On Thu, 28 Feb 2013, Adrian Bassett wrote:
> > First, things will be a lot easier if you do your testing with a 3.8
> > kernel rather than 3.7.7.
>
> Ok. using 3.8 checked out from the linux-stable git tree from kernel.org. I built three test kernels - 1/ vanilla, 2/ 640c3339 reverted, 3/ no revert but incorporating your patch.
And presumably the first failed, the second worked, and the third failed.
> > Second, just to be certain we are on the same page, is it correct that
> > you find suspend works okay when you revert commit 6e0c3339a6f19d7 but
> > it fails if the commit is in place?
>
> That's correct. Excepting I think that with 3.8 (possibly with 3.7.7 also but I haven't re-run the tests) it's with resume rather than suspend where the problem lies. What I've found is that a number of suspend/resume cycles (in close succession) will work OK but then resume will delay for several minutes before returning the system. Network is usually a problem if resume attempts follow suspend too soon. External USB mass storage has not always been re-available, either.
Obviously this is because your USB mass storage and wireless devices
are attached to the EHCI controller.
> > Third: Does applying the patch below help at all?
>
> It didn't appear to, in my tests.
>
> > Fourth: If not, please build a kernel with CONFIG_USB_DEBUG enabled and
> > post the output from dmesg following a failed suspend attempt.
>
> Following output is from /var/log/messages, filtered on kernel: messages and with cfg80211 llines removed for brevity (well, it's not brief but perhaps it will be useful).
This is all rather odd. Evidently the EHCI controller stopped working
for a while and then started working again.
Also, I don't know what this and the related warnings are all about:
> Feb 28 14:56:14 mypc kernel: ------------[ cut here ]------------
> Feb 28 14:56:14 mypc kernel: WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2223 ath9k_hw_setpower+0x355/0x590 [ath9k_hw]()
> Feb 28 14:56:14 mypc kernel: Hardware name: G41MT-S2P
> Feb 28 14:56:14 mypc kernel: Modules linked in: it87 hwmon_vid tcp_westwood i915 ath9k_htc ath9k_common ath9k_hw pwc drm_kms_helper videobuf2_vmalloc videobuf2_memops drm videobuf2_core cpufreq_ondemand rtl8180 ath eeprom_93cx6 coretemp uhci_hcd ehci_pci ehci_hcd
> Feb 28 14:56:14 mypc kernel: Pid: 14318, comm: s2ram Not tainted 3.8.0-patched-00002-g10460f0-dirty #1
> Feb 28 14:56:14 mypc kernel: Call Trace:
> Feb 28 14:56:14 mypc kernel: [<ffffffff810439da>] warn_slowpath_common+0x7a/0xb0
> Feb 28 14:56:14 mypc kernel: [<ffffffff81043a25>] warn_slowpath_null+0x15/0x20
> Feb 28 14:56:14 mypc kernel: [<ffffffffa00cd465>] ath9k_hw_setpower+0x355/0x590 [ath9k_hw]
> Feb 28 14:56:14 mypc kernel: [<ffffffffa0144106>] ath9k_htc_setpower+0x36/0x60 [ath9k_htc]
> Feb 28 14:56:14 mypc kernel: [<ffffffffa0144d76>] ath9k_htc_start+0x56/0x260 [ath9k_htc]
> Feb 28 14:56:14 mypc kernel: [<ffffffff8182c7a1>] ieee80211_reconfig+0x1b1/0x2360
> Feb 28 14:56:14 mypc kernel: [<ffffffff81876ef1>] ? _raw_spin_lock_bh+0x11/0x40
> Feb 28 14:56:14 mypc kernel: [<ffffffff817b9639>] ? wiphy_resume+0x59/0x1c0
> Feb 28 14:56:14 mypc kernel: [<ffffffff8181d3c8>] ieee80211_resume+0x28/0x70
> Feb 28 14:56:14 mypc kernel: [<ffffffff817b969a>] wiphy_resume+0xba/0x1c0
> Feb 28 14:56:14 mypc kernel: [<ffffffff817b95e0>] ? index_show+0x30/0x30
> Feb 28 14:56:14 mypc kernel: [<ffffffff8142c106>] dpm_run_callback.isra.5+0x36/0x70
> Feb 28 14:56:14 mypc kernel: [<ffffffff8142c41f>] device_resume+0x9f/0x140
> Feb 28 14:56:14 mypc kernel: [<ffffffff8142d34c>] dpm_resume+0xfc/0x230
> Feb 28 14:56:14 mypc kernel: [<ffffffff8142d650>] dpm_resume_end+0x10/0x20
> Feb 28 14:56:14 mypc kernel: [<ffffffff813bc8d1>] ? acpi_suspend_begin_old+0x28/0x28
> Feb 28 14:56:14 mypc kernel: [<ffffffff8108c12d>] suspend_devices_and_enter+0x13d/0x370
> Feb 28 14:56:14 mypc kernel: [<ffffffff8108c4eb>] pm_suspend+0x18b/0x1f0
> Feb 28 14:56:14 mypc kernel: [<ffffffff8108b4e9>] state_store+0x89/0xf0
> Feb 28 14:56:14 mypc kernel: [<ffffffff8136898f>] kobj_attr_store+0xf/0x30
> Feb 28 14:56:14 mypc kernel: [<ffffffff811b74ed>] sysfs_write_file+0xdd/0x160
> Feb 28 14:56:14 mypc kernel: [<ffffffff8114b3fa>] vfs_write+0xaa/0x180
> Feb 28 14:56:14 mypc kernel: [<ffffffff8114b72d>] sys_write+0x4d/0x90
> Feb 28 14:56:14 mypc kernel: [<ffffffff8187e152>] system_call_fastpath+0x16/0x1b
> Feb 28 14:56:14 mypc kernel: ---[ end trace fd27824e37f48d17 ]---
> Feb 28 14:56:14 mypc kernel: ath: phy2: timeout (100000 us) on reg 0x7000: 0xfffffffb & 0x00000003 != 0x00000000
> Feb 28 14:56:14 mypc kernel: ath: phy2: Chip reset failed
> Feb 28 14:56:14 mypc kernel: ath: phy2: Unable to reset hardware; reset status -22 (freq 2462 MHz)
They look like a bug in the ath9k driver.
Anyway, the problem appears to be that the EHCI controller isn't
issuing IRQs as it should. Does the patch below make any difference?
It turns on the I/O watchdog timer for async transfers on Intel
hardware.
Finally, I don't see how this could possibly have any connection with
the 6e0c3339a6 commit (USB: EHCI: unlink one async QH at a time). If
necessary, we can try a diagnostic patch to see what's going on with
the async QH unlinking.
Alan Stern
Index: 3.8/drivers/usb/host/ehci-pci.c
===================================================================
--- 3.8.orig/drivers/usb/host/ehci-pci.c
+++ 3.8/drivers/usb/host/ehci-pci.c
@@ -230,7 +230,6 @@ static int ehci_pci_setup(struct usb_hcd
ehci->need_io_watchdog = 0;
break;
case PCI_VENDOR_ID_INTEL:
- ehci->need_io_watchdog = 0;
break;
case PCI_VENDOR_ID_NVIDIA:
switch (pdev->device) {
--
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
