Re: problem with resume after s2ram
On Wed, Apr 30 2014, Alan Stern wrote: Okay, good. Below is a patch which I hope will fix your problem. You can leave diag1 in place if you want, but remove all the other patches. Hi Alan, Yes, it works very well with latest git-kernel (3.15-rc3). Thanks, -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 29 Apr 2014, Peter Münster wrote:
On Tue, Apr 29 2014, Alan Stern wrote:
It's noticeable that your logs include resets of the affected devices,
whereas the older kernels did not need any resets. This suggests that
these OHCI controllers will always have problems with global suspend,
and therefore a controller-specific fix is needed.
Perhaps this is related:
https://mailman.archlinux.org/pipermail/arch-general/2014-January/034831.html
I can't tell.
Can you post the output from lspci -v -s 12.1
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB
OHCI1 Controller (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 8389
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
Memory at f8ffd000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Okay, good. Below is a patch which I hope will fix your problem. You
can leave diag1 in place if you want, but remove all the other patches.
Alan Stern
Index: usb-3.15/drivers/usb/host/ohci-hub.c
===
--- usb-3.15.orig/drivers/usb/host/ohci-hub.c
+++ usb-3.15/drivers/usb/host/ohci-hub.c
@@ -90,6 +90,24 @@ __acquires(ohci-lock)
dl_done_list (ohci);
finish_unlinks (ohci, ohci_frame_no(ohci));
+ /*
+* Some controllers don't handle global suspend properly if
+* there are unsuspended ports. For these controllers, put all
+* the enabled ports into suspend before suspending the root hub.
+*/
+ if (ohci-flags OHCI_QUIRK_GLOBAL_SUSPEND) {
+ __hc32 __iomem *portstat = ohci-regs-roothub.portstatus;
+ int i;
+ unsignedtemp;
+
+ for (i = 0; i ohci-num_ports; (++i, ++portstat)) {
+ temp = ohci_readl(ohci, portstat);
+ if ((temp (RH_PS_PES | RH_PS_PSS)) ==
+ RH_PS_PES)
+ ohci_writel(ohci, RH_PS_PSS, portstat);
+ }
+ }
+
/* maybe resume can wake root hub */
if (ohci_to_hcd(ohci)-self.root_hub-do_remote_wakeup || autostop) {
ohci-hc_control |= OHCI_CTRL_RWE;
Index: usb-3.15/drivers/usb/host/ohci-pci.c
===
--- usb-3.15.orig/drivers/usb/host/ohci-pci.c
+++ usb-3.15/drivers/usb/host/ohci-pci.c
@@ -160,6 +160,7 @@ static int ohci_quirk_amd700(struct usb_
ohci_dbg(ohci, enabled AMD prefetch quirk\n);
}
+ ohci-flags |= OHCI_QUIRK_GLOBAL_SUSPEND;
return 0;
}
Index: usb-3.15/drivers/usb/host/ohci.h
===
--- usb-3.15.orig/drivers/usb/host/ohci.h
+++ usb-3.15/drivers/usb/host/ohci.h
@@ -405,6 +405,8 @@ struct ohci_hcd {
#defineOHCI_QUIRK_HUB_POWER0x100 /* distrust
firmware power/oc setup */
#defineOHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL
quirk*/
#defineOHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch
for ISO transfer */
+#defineOHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend
ports */
+
// there are also chip quirks/bugs in init logic
struct work_struct nec_work; /* Worker for NEC quirk */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Mon, Apr 28 2014, Alan Stern wrote: That's interesting. Here's another test you should try with that same kernel. Start moving the mouse before you wake up the system, and keep moving it until the system has fully resumed. When you do this, does it work right? That is, when the screen turns back on, do you see the mouse cursor moving around? Yes, it works. Below is the next patch in the series, diag6. This adds back more material that was removeed in diag5. My guess is that this one will cause your system to crash during resume. No, it does not crash. Please find attached the log. There are 2 s2ram-wakeup cycles, first wakeup with keyboard and second with power-button. During both wakeups I've moved the mouse. -- Peter 2014-04-29T11:26:02.267472+02:00 micropit kernel: [ 174.451250] PM: Syncing filesystems ... done. 2014-04-29T11:26:02.267520+02:00 micropit kernel: [ 174.614390] PM: Preparing system for mem sleep 2014-04-29T11:26:02.320493+02:00 micropit kernel: [ 174.27] ohci-pci :00:12.1: Dequeue: 8801294c6680 count 1 2014-04-29T11:26:02.320533+02:00 micropit kernel: [ 174.667577] ohci-pci :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame a5e4 2014-04-29T11:26:02.320547+02:00 micropit kernel: [ 174.667637] ohci-pci :00:12.1: Giveback: 8801294c6680 count 1 2014-04-29T11:26:24.703742+02:00 micropit kernel: [ 174.693123] Freezing user space processes ... (elapsed 0.001 seconds) done. 2014-04-29T11:26:24.703764+02:00 micropit kernel: [ 174.694873] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 2014-04-29T11:26:24.703765+02:00 micropit kernel: [ 174.696288] PM: Entering mem sleep 2014-04-29T11:26:24.703766+02:00 micropit kernel: [ 174.697067] usb 3-2: usb suspend, wakeup 0 2014-04-29T11:26:24.703766+02:00 micropit kernel: [ 174.697079] usb 4-3: usb suspend, wakeup 0 2014-04-29T11:26:24.703767+02:00 micropit kernel: [ 174.697113] ohci-pci :00:12.1: Dequeue: 8801242568c0 count 1 2014-04-29T11:26:24.703768+02:00 micropit kernel: [ 174.697177] usb 2-3: usb suspend, wakeup 0 2014-04-29T11:26:24.703769+02:00 micropit kernel: [ 174.697248] sd 2:0:0:0: [sdb] Synchronizing SCSI cache 2014-04-29T11:26:24.703769+02:00 micropit kernel: [ 174.697319] sd 0:0:0:0: [sda] Synchronizing SCSI cache 2014-04-29T11:26:24.703770+02:00 micropit kernel: [ 174.697375] usb usb7: usb auto-resume 2014-04-29T11:26:24.703771+02:00 micropit kernel: [ 174.697384] ohci-pci :00:14.5: resume root hub 2014-04-29T11:26:24.703771+02:00 micropit kernel: [ 174.697398] usb 1-4: usb suspend, wakeup 0 2014-04-29T11:26:24.703772+02:00 micropit kernel: [ 174.697425] usb usb6: usb auto-resume 2014-04-29T11:26:24.703773+02:00 micropit kernel: [ 174.697432] ohci-pci :00:13.1: resume root hub 2014-04-29T11:26:24.703774+02:00 micropit kernel: [ 174.697524] ohci-pci :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame a602 2014-04-29T11:26:24.703775+02:00 micropit kernel: [ 174.697528] usb usb5: usb auto-resume 2014-04-29T11:26:24.703775+02:00 micropit kernel: [ 174.697537] ohci-pci :00:13.0: resume root hub 2014-04-29T11:26:24.703776+02:00 micropit kernel: [ 174.697843] ohci-pci :00:12.1: Giveback: 8801242568c0 count 1 2014-04-29T11:26:24.703777+02:00 micropit kernel: [ 174.698201] sd 0:0:0:0: [sda] Stopping disk 2014-04-29T11:26:24.703778+02:00 micropit kernel: [ 174.698548] usb 4-2: usb suspend, wakeup 1 2014-04-29T11:26:24.703778+02:00 micropit kernel: [ 174.698622] hub 3-0:1.0: hub_suspend 2014-04-29T11:26:24.703779+02:00 micropit kernel: [ 174.698694] hub 2-0:1.0: hub_suspend 2014-04-29T11:26:24.703780+02:00 micropit kernel: [ 174.698698] usb usb3: bus suspend, wakeup 0 2014-04-29T11:26:24.703781+02:00 micropit kernel: [ 174.698705] ohci-pci :00:12.0: suspend root hub 2014-04-29T11:26:24.703781+02:00 micropit kernel: [ 174.698727] hub 1-0:1.0: hub_suspend 2014-04-29T11:26:24.703782+02:00 micropit kernel: [ 174.698744] usb usb1: bus suspend, wakeup 0 2014-04-29T11:26:24.703783+02:00 micropit kernel: [ 174.698748] ehci-pci :00:12.2: suspend root hub 2014-04-29T11:26:24.703783+02:00 micropit kernel: [ 174.698812] usb usb2: bus suspend, wakeup 0 2014-04-29T11:26:24.703784+02:00 micropit kernel: [ 174.698836] ehci-pci :00:13.2: suspend root hub 2014-04-29T11:26:24.703785+02:00 micropit kernel: [ 174.698978] hub 4-0:1.0: hub_suspend 2014-04-29T11:26:24.703786+02:00 micropit kernel: [ 174.699014] usb usb4: bus suspend, wakeup 0 2014-04-29T11:26:24.703786+02:00 micropit kernel: [ 174.699035] ohci-pci :00:12.1: suspend root hub 2014-04-29T11:26:24.703787+02:00 micropit kernel: [ 174.699079] nouveau [ DRM] suspending fbcon... 2014-04-29T11:26:24.703788+02:00 micropit kernel: [ 174.699102] nouveau [ DRM] suspending display... 2014-04-29T11:26:24.703788+02:00 micropit kernel: [ 174.699117] nouveau [ DRM] unpinning framebuffer(s)... 2014-04-29T11:26:24.703789+02:00
Re: problem with resume after s2ram
On Tue, 29 Apr 2014, Peter Münster wrote: On Mon, Apr 28 2014, Alan Stern wrote: That's interesting. Here's another test you should try with that same kernel. Start moving the mouse before you wake up the system, and keep moving it until the system has fully resumed. When you do this, does it work right? That is, when the screen turns back on, do you see the mouse cursor moving around? Yes, it works. Below is the next patch in the series, diag6. This adds back more material that was removeed in diag5. My guess is that this one will cause your system to crash during resume. No, it does not crash. Please find attached the log. There are 2 s2ram-wakeup cycles, first wakeup with keyboard and second with power-button. During both wakeups I've moved the mouse. Ha! I guess that shows I still don't understand what's going on. It's noticeable that your logs include resets of the affected devices, whereas the older kernels did not need any resets. This suggests that these OHCI controllers will always have problems with global suspend, and therefore a controller-specific fix is needed. Can you post the output from lspci -v -s 12.1 and lspci -v -n -s 12.1? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 29 2014, Alan Stern wrote: It's noticeable that your logs include resets of the affected devices, whereas the older kernels did not need any resets. This suggests that these OHCI controllers will always have problems with global suspend, and therefore a controller-specific fix is needed. Perhaps this is related: https://mailman.archlinux.org/pipermail/arch-general/2014-January/034831.html Can you post the output from lspci -v -s 12.1 00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8389 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f8ffd000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd and lspci -v -n -s 12.1? 00:12.1 0c03: 1002:4398 (prog-if 10 [OHCI]) Subsystem: 1043:8389 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f8ffd000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Sat, 26 Apr 2014, Peter Münster wrote:
On Tue, Apr 22 2014, Alan Stern wrote:
Here's diag5; it's essentially a subset of diag4. Test it in the same
way.
(Not being able to wake up the system from the keyboard is expected
for diag4. With diag5, you may or may not be able to use the keyboard
for wakeup -- try it and see. It's even possible that the system will
crash if you use the keyboard but not if you use the power button!)
Hi Alan,
I can wakeup with the keyboard and there is no crash. Please find
attached the log. There are 2 s2ram-wakeup cycles: the first wakeup is
with the power-button, the second with the keyboard.
That's interesting. Here's another test you should try with that same
kernel. Start moving the mouse before you wake up the system, and keep
moving it until the system has fully resumed. When you do this, does
it work right? That is, when the screen turns back on, do you see the
mouse cursor moving around?
Below is the next patch in the series, diag6. This adds back more
material that was removeed in diag5. My guess is that this one will
cause your system to crash during resume.
Alan Stern
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2981,7 +2981,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (0)
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
@@ -3107,38 +3107,6 @@ static int finish_port_resume(struct usb
if (status) {
dev_dbg(udev-dev, gone after usb resume? status %d\n,
status);
- /*
-* There are a few quirky devices which violate the standard
-* by claiming to have remote wakeup enabled after a reset,
-* which crash if the feature is cleared, hence check for
-* udev-reset_resume
-*/
- } else if (udev-actconfig !udev-reset_resume) {
- if (!hub_is_superspeed(udev-parent)) {
- le16_to_cpus(devstatus);
- if (devstatus (1 USB_DEVICE_REMOTE_WAKEUP))
- status = usb_control_msg(udev,
- usb_sndctrlpipe(udev, 0),
- USB_REQ_CLEAR_FEATURE,
- USB_RECIP_DEVICE,
- USB_DEVICE_REMOTE_WAKEUP, 0,
- NULL, 0,
- USB_CTRL_SET_TIMEOUT);
- } else {
- status = usb_get_status(udev, USB_RECIP_INTERFACE, 0,
- devstatus);
- le16_to_cpus(devstatus);
- if (!status devstatus (USB_INTRF_STAT_FUNC_RW_CAP
- | USB_INTRF_STAT_FUNC_RW))
- status =
- usb_disable_function_remotewakeup(udev);
- }
-
- if (status)
- dev_dbg(udev-dev,
- disable remote wakeup, status %d\n,
- status);
- status = 0;
}
return status;
}
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 22 2014, Alan Stern wrote: Here's diag5; it's essentially a subset of diag4. Test it in the same way. (Not being able to wake up the system from the keyboard is expected for diag4. With diag5, you may or may not be able to use the keyboard for wakeup -- try it and see. It's even possible that the system will crash if you use the keyboard but not if you use the power button!) Hi Alan, I can wakeup with the keyboard and there is no crash. Please find attached the log. There are 2 s2ram-wakeup cycles: the first wakeup is with the power-button, the second with the keyboard. -- Peter 2014-04-26T23:18:23.150469+02:00 micropit kernel: [ 165.435730] ohci-pci :00:12.1: Dequeue: 880123f6c140 count 1 2014-04-26T23:18:23.150549+02:00 micropit kernel: [ 165.436357] ohci-pci :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame 80dd 2014-04-26T23:18:23.150554+02:00 micropit kernel: [ 165.436399] ohci-pci :00:12.1: Giveback: 880123f6c140 count 1 2014-04-26T23:18:23.931590+02:00 micropit kernel: [ 165.783404] PM: Syncing filesystems ... done. 2014-04-26T23:18:23.931637+02:00 micropit kernel: [ 166.217701] PM: Preparing system for mem sleep 2014-04-26T23:18:41.671338+02:00 micropit kernel: [ 166.220770] Freezing user space processes ... (elapsed 0.001 seconds) done. 2014-04-26T23:18:41.671361+02:00 micropit kernel: [ 166.222885] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 2014-04-26T23:18:41.671362+02:00 micropit kernel: [ 166.224457] PM: Entering mem sleep 2014-04-26T23:18:41.671363+02:00 micropit kernel: [ 166.225109] usb 3-2: usb suspend, wakeup 0 2014-04-26T23:18:41.671364+02:00 micropit kernel: [ 166.225206] ohci-pci :00:12.1: Dequeue: 880123f6cb00 count 1 2014-04-26T23:18:41.671364+02:00 micropit kernel: [ 166.225213] usb 4-3: usb suspend, wakeup 0 2014-04-26T23:18:41.671365+02:00 micropit kernel: [ 166.225230] usb 2-3: usb suspend, wakeup 0 2014-04-26T23:18:41.671366+02:00 micropit kernel: [ 166.225246] usb 1-4: usb suspend, wakeup 0 2014-04-26T23:18:41.671367+02:00 micropit kernel: [ 166.225304] sd 2:0:0:0: [sdb] Synchronizing SCSI cache 2014-04-26T23:18:41.671368+02:00 micropit kernel: [ 166.225524] sd 0:0:0:0: [sda] Synchronizing SCSI cache 2014-04-26T23:18:41.671369+02:00 micropit kernel: [ 166.225771] usb usb7: usb auto-resume 2014-04-26T23:18:41.671369+02:00 micropit kernel: [ 166.225777] ohci-pci :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame 83f2 2014-04-26T23:18:41.671370+02:00 micropit kernel: [ 166.225786] ohci-pci :00:12.1: Giveback: 880123f6cb00 count 1 2014-04-26T23:18:41.671371+02:00 micropit kernel: [ 166.225931] usb usb6: usb auto-resume 2014-04-26T23:18:41.671372+02:00 micropit kernel: [ 166.225941] ohci-pci :00:13.1: resume root hub 2014-04-26T23:18:41.671373+02:00 micropit kernel: [ 166.226065] ohci-pci :00:14.5: resume root hub 2014-04-26T23:18:41.671374+02:00 micropit kernel: [ 166.226080] usb usb5: usb auto-resume 2014-04-26T23:18:41.671374+02:00 micropit kernel: [ 166.226091] ohci-pci :00:13.0: resume root hub 2014-04-26T23:18:41.671375+02:00 micropit kernel: [ 166.226221] hub 3-0:1.0: hub_suspend 2014-04-26T23:18:41.671376+02:00 micropit kernel: [ 166.226237] usb usb3: bus suspend, wakeup 0 2014-04-26T23:18:41.671377+02:00 micropit kernel: [ 166.226244] ohci-pci :00:12.0: suspend root hub 2014-04-26T23:18:41.671378+02:00 micropit kernel: [ 166.226286] hub 2-0:1.0: hub_suspend 2014-04-26T23:18:41.671379+02:00 micropit kernel: [ 166.226292] usb usb2: bus suspend, wakeup 0 2014-04-26T23:18:41.671379+02:00 micropit kernel: [ 166.226296] ehci-pci :00:13.2: suspend root hub 2014-04-26T23:18:41.671380+02:00 micropit kernel: [ 166.226481] hub 1-0:1.0: hub_suspend 2014-04-26T23:18:41.671381+02:00 micropit kernel: [ 166.226493] usb usb1: bus suspend, wakeup 0 2014-04-26T23:18:41.671382+02:00 micropit kernel: [ 166.226497] ehci-pci :00:12.2: suspend root hub 2014-04-26T23:18:41.671383+02:00 micropit kernel: [ 166.226822] usb 4-2: usb suspend, wakeup 1 2014-04-26T23:18:41.671384+02:00 micropit kernel: [ 166.226872] hub 4-0:1.0: hub_suspend 2014-04-26T23:18:41.671384+02:00 micropit kernel: [ 166.226882] usb usb4: bus suspend, wakeup 0 2014-04-26T23:18:41.671385+02:00 micropit kernel: [ 166.226890] ohci-pci :00:12.1: suspend root hub 2014-04-26T23:18:41.671386+02:00 micropit kernel: [ 166.246797] sd 2:0:0:0: [sdb] Stopping disk 2014-04-26T23:18:41.671387+02:00 micropit kernel: [ 166.274302] hub 6-0:1.0: hub_resume 2014-04-26T23:18:41.671388+02:00 micropit kernel: [ 166.274315] hub 5-0:1.0: hub_resume 2014-04-26T23:18:41.671388+02:00 micropit kernel: [ 166.274358] hub 5-0:1.0: hub_suspend 2014-04-26T23:18:41.671389+02:00 micropit kernel: [ 166.274369] usb usb5: bus suspend, wakeup 0 2014-04-26T23:18:41.671390+02:00 micropit kernel: [ 166.274377] ohci-pci :00:13.0: suspend root hub 2014-04-26T23:18:41.671391+02:00
Re: problem with resume after s2ram
On Mon, Apr 21 2014, Alan Stern wrote: Here's a new diagnostic patch (diag4) to try, on the same kernel, along with diag1 and nothing else. This patch does almost the same thing as turning off CONFIG_USB_SUSPEND used to do in earlier versions of the kernel. If the behavior is consistent, this should work with both the keyboard and mouse attached to the rear ports. Hi Alan, Yes it works. I need to press the power button to wake up the system, but that's not a problem. Please find attached the log. -- Peter 2014-04-22T08:52:37.136318+02:00 micropit kernel: [ 164.986690] PM: Syncing filesystems ... done. 2014-04-22T08:52:37.136364+02:00 micropit kernel: [ 165.412400] PM: Preparing system for mem sleep 2014-04-22T08:53:13.669485+02:00 micropit kernel: [ 165.414614] Freezing user space processes ... (elapsed 0.001 seconds) done. 2014-04-22T08:53:13.669518+02:00 micropit kernel: [ 165.416602] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 2014-04-22T08:53:13.669522+02:00 micropit kernel: [ 165.418147] PM: Entering mem sleep 2014-04-22T08:53:13.669525+02:00 micropit kernel: [ 165.419080] ohci-pci :00:12.1: Dequeue: 880129fcf780 count 1 2014-04-22T08:53:13.669528+02:00 micropit kernel: [ 165.419181] sd 2:0:0:0: [sdb] Synchronizing SCSI cache 2014-04-22T08:53:13.669530+02:00 micropit kernel: [ 165.419379] sd 0:0:0:0: [sda] Synchronizing SCSI cache 2014-04-22T08:53:13.669533+02:00 micropit kernel: [ 165.419507] ohci-pci :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame 80c8 2014-04-22T08:53:13.669536+02:00 micropit kernel: [ 165.419594] ohci-pci :00:12.1: Giveback: 880129fcf780 count 1 2014-04-22T08:53:13.669538+02:00 micropit kernel: [ 165.419651] usb usb7: usb auto-resume 2014-04-22T08:53:13.669541+02:00 micropit kernel: [ 165.419663] ohci-pci :00:14.5: resume root hub 2014-04-22T08:53:13.669544+02:00 micropit kernel: [ 165.419771] usb usb6: usb auto-resume 2014-04-22T08:53:13.669546+02:00 micropit kernel: [ 165.419804] usb usb5: usb auto-resume 2014-04-22T08:53:13.669549+02:00 micropit kernel: [ 165.419813] ohci-pci :00:13.0: resume root hub 2014-04-22T08:53:13.669551+02:00 micropit kernel: [ 165.419909] hub 3-0:1.0: hub_suspend 2014-04-22T08:53:13.669554+02:00 micropit kernel: [ 165.419919] hub 4-0:1.0: hub_suspend 2014-04-22T08:53:13.669556+02:00 micropit kernel: [ 165.419923] usb usb3: bus suspend, wakeup 0 2014-04-22T08:53:13.669558+02:00 micropit kernel: [ 165.419929] ohci-pci :00:12.0: suspend root hub 2014-04-22T08:53:13.669561+02:00 micropit kernel: [ 165.419935] usb usb4: bus suspend, wakeup 0 2014-04-22T08:53:13.669563+02:00 micropit kernel: [ 165.419943] ohci-pci :00:12.1: suspend root hub 2014-04-22T08:53:13.669566+02:00 micropit kernel: [ 165.419981] hub 2-0:1.0: hub_suspend 2014-04-22T08:53:13.669568+02:00 micropit kernel: [ 165.419989] usb usb2: bus suspend, wakeup 0 2014-04-22T08:53:13.669571+02:00 micropit kernel: [ 165.420001] ehci-pci :00:13.2: suspend root hub 2014-04-22T08:53:13.669573+02:00 micropit kernel: [ 165.420318] hub 1-0:1.0: hub_suspend 2014-04-22T08:53:13.669575+02:00 micropit kernel: [ 165.420329] usb usb1: bus suspend, wakeup 0 2014-04-22T08:53:13.669578+02:00 micropit kernel: [ 165.420332] ehci-pci :00:12.2: suspend root hub 2014-04-22T08:53:13.669581+02:00 micropit kernel: [ 165.420877] ohci-pci :00:13.1: resume root hub 2014-04-22T08:53:13.669583+02:00 micropit kernel: [ 165.440342] sd 2:0:0:0: [sdb] Stopping disk 2014-04-22T08:53:13.669585+02:00 micropit kernel: [ 165.468346] hub 7-0:1.0: hub_resume 2014-04-22T08:53:13.669588+02:00 micropit kernel: [ 165.468352] hub 5-0:1.0: hub_resume 2014-04-22T08:53:13.669590+02:00 micropit kernel: [ 165.468393] hub 5-0:1.0: hub_suspend 2014-04-22T08:53:13.669592+02:00 micropit kernel: [ 165.468405] usb usb5: bus suspend, wakeup 0 2014-04-22T08:53:13.669595+02:00 micropit kernel: [ 165.468411] ohci-pci :00:13.0: suspend root hub 2014-04-22T08:53:13.669597+02:00 micropit kernel: [ 165.468938] hub 7-0:1.0: hub_suspend 2014-04-22T08:53:13.669600+02:00 micropit kernel: [ 165.469055] usb usb7: bus suspend, wakeup 0 2014-04-22T08:53:13.669602+02:00 micropit kernel: [ 165.469168] ohci-pci :00:14.5: suspend root hub 2014-04-22T08:53:13.669604+02:00 micropit kernel: [ 165.469410] hub 6-0:1.0: hub_resume 2014-04-22T08:53:13.669607+02:00 micropit kernel: [ 165.469567] hub 6-0:1.0: hub_suspend 2014-04-22T08:53:13.669609+02:00 micropit kernel: [ 165.469684] usb usb6: bus suspend, wakeup 0 2014-04-22T08:53:13.669611+02:00 micropit kernel: [ 165.469798] ohci-pci :00:13.1: suspend root hub 2014-04-22T08:53:13.669614+02:00 micropit kernel: [ 165.474512] sd 0:0:0:0: [sda] Stopping disk 2014-04-22T08:53:13.669616+02:00 micropit kernel: [ 166.345681] PM: suspend of devices complete after 926.443 msecs 2014-04-22T08:53:13.669619+02:00 micropit kernel: [ 166.346251] PM: late suspend of devices
Re: problem with resume after s2ram
On Sun, 20 Apr 2014, Peter Münster wrote:
On Fri, Apr 18 2014, Alan Stern wrote:
Below is a first simple attempt, let's call it fix1. This should be
applied to the kernel you have been using, with diag1 but without any
of the diag3* patches. What happens with fix1 and with the mouse
plugged into the rear?
Hi Alan,
It does not work. Please find attached the log.
All right; it was a long shot anyway.
Here's a new diagnostic patch (diag4) to try, on the same kernel, along
with diag1 and nothing else. This patch does almost the same thing as
turning off CONFIG_USB_SUSPEND used to do in earlier versions of the
kernel. If the behavior is consistent, this should work with both the
keyboard and mouse attached to the rear ports.
Alan Stern
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2907,144 +2907,11 @@ static unsigned wakeup_enabled_descendan
*/
int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
{
- struct usb_hub *hub = usb_hub_to_struct_hub(udev-parent);
- struct usb_port *port_dev = hub-ports[udev-portnum - 1];
- enum pm_qos_flags_status pm_qos_stat;
- int port1 = udev-portnum;
int status;
- boolreally_suspend = true;
-
- /* enable remote wakeup when appropriate; this lets the device
-* wake up the upstream hub (including maybe the root hub).
-*
-* NOTE: OTG devices may issue remote wakeup (or SRP) even when
-* we don't explicitly enable it here.
-*/
- if (udev-do_remote_wakeup) {
- if (!hub_is_superspeed(hub-hdev)) {
- status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
- USB_REQ_SET_FEATURE, USB_RECIP_DEVICE,
- USB_DEVICE_REMOTE_WAKEUP, 0,
- NULL, 0,
- USB_CTRL_SET_TIMEOUT);
- } else {
- /* Assume there's only one function on the USB 3.0
-* device and enable remote wake for the first
-* interface. FIXME if the interface association
-* descriptor shows there's more than one function.
-*/
- status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
- USB_REQ_SET_FEATURE,
- USB_RECIP_INTERFACE,
- USB_INTRF_FUNC_SUSPEND,
- USB_INTRF_FUNC_SUSPEND_RW |
- USB_INTRF_FUNC_SUSPEND_LP,
- NULL, 0,
- USB_CTRL_SET_TIMEOUT);
- }
- if (status) {
- dev_dbg(udev-dev, won't remote wakeup, status %d\n,
- status);
- /* bail if autosuspend is requested */
- if (PMSG_IS_AUTO(msg))
- return status;
- }
- }
-
- /* disable USB2 hardware LPM */
- if (udev-usb2_hw_lpm_enabled == 1)
- usb_set_usb2_hardware_lpm(udev, 0);
-
- if (usb_disable_ltm(udev)) {
- dev_err(udev-dev, %s Failed to disable LTM before
suspend\n.,
- __func__);
- return -ENOMEM;
- }
- if (usb_unlocked_disable_lpm(udev)) {
- dev_err(udev-dev, %s Failed to disable LPM before
suspend\n.,
- __func__);
- return -ENOMEM;
- }
- /* see 7.1.7.6 */
- if (hub_is_superspeed(hub-hdev))
- status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
-
- /*
-* For system suspend, we do not need to enable the suspend feature
-* on individual USB-2 ports. The devices will automatically go
-* into suspend a few ms after the root hub stops sending packets.
-* The USB 2.0 spec calls this global suspend.
-*
-* However, many USB hubs have a bug: They don't relay wakeup requests
-* from a downstream port if the port's suspend feature isn't on.
-* Therefore we will turn on the suspend feature if udev or any of its
-* descendants is enabled for remote wakeup.
-*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
- status = set_port_feature(hub-hdev, port1,
- USB_PORT_FEAT_SUSPEND);
- else {
- really_suspend = false;
status = 0;
- }
- if (status) {
- dev_dbg(hub-intfdev, can't suspend port %d, status
Re: problem with resume after s2ram
On Thu, Apr 17 2014, Peter Münster wrote: On Thu, Apr 17 2014, Alan Stern wrote: Just to verify, please try replacing diag3 with each of the two patches below (one at a time). If my guess is right, diag3a will work and diag3b will fail. Yes, you're right! Sorry, I've forgotten the logs. For which patch do you need logs? -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Fri, 18 Apr 2014, Peter Münster wrote: On Thu, Apr 17 2014, Peter Münster wrote: On Thu, Apr 17 2014, Alan Stern wrote: Just to verify, please try replacing diag3 with each of the two patches below (one at a time). If my guess is right, diag3a will work and diag3b will fail. Yes, you're right! Sorry, I've forgotten the logs. For which patch do you need logs? The logs aren't necessary. The real point of those tests was to check that the hardware really does behave inconsistently. It appears that the same problem affects the front ports and the rear ports, but it affects them in slightly different ways. The controller for the rear crashes if any ports are unsuspended, whereas the controller for the front crashes if some ports are unsuspended and some are suspended. This means we have to try to fix the problem. Below is a first simple attempt, let's call it fix1. This should be applied to the kernel you have been using, with diag1 but without any of the diag3* patches. What happens with fix1 and with the mouse plugged into the rear? (I'd be a little surprised if it worked, but you never know...) Alan Stern Index: peter/drivers/usb/core/hub.c === --- peter.orig/drivers/usb/core/hub.c +++ peter/drivers/usb/core/hub.c @@ -3197,8 +3197,6 @@ int usb_port_resume(struct usb_device *u /* Skip the initial Clear-Suspend step for a remote wakeup */ status = hub_port_status(hub, port1, portstatus, portchange); - if (status == 0 !port_is_suspended(hub, portstatus)) - goto SuspendCleared; // dev_dbg(hub-intfdev, resume port %d\n, port1); -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Wed, 16 Apr 2014, Peter Münster wrote:
On Mon, Apr 14 2014, Alan Stern wrote:
How many diagnostic patches have you tried so far? I've lost track.
Hi Alan,
diag1: the one with the alan-timer
diag2: reverts commit 0aa2832dd0d9d860 and instead, prints
out information showing what the commit would do
diag3: partially reverts e583d9db9960 and prints some information to the
kernel log
If you like, you can also apply the diagnostic patch that adds stuff
to ohci-hcd.
Yes, I've applied diag1 and diag3.
The question is: With this patch present and no devices attached to the
rear ports, do the front ports work with system suspend?
Yes. Please find attached the log.
This is really crazy. It appears to indicate that the OHCI controller
for your bus 6 works okay when both the connected ports are in suspend
or neither of them is, but not when one is and one isn't!
Just to verify, please try replacing diag3 with each of the two patches
below (one at a time). If my guess is right, diag3a will work and
diag3b will fail.
Alan Stern
diag3a
--
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2966,6 +2966,8 @@ int usb_port_suspend(struct usb_device *
return -ENOMEM;
}
+ dev_info(udev-dev, w-e-d %d\n, wakeup_enabled_descendants(udev));
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
@@ -2981,7 +2983,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (1)
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
diag3b
--
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2966,6 +2966,8 @@ int usb_port_suspend(struct usb_device *
return -ENOMEM;
}
+ dev_info(udev-dev, w-e-d %d\n, wakeup_enabled_descendants(udev));
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Thu, Apr 17 2014, Alan Stern wrote: Just to verify, please try replacing diag3 with each of the two patches below (one at a time). If my guess is right, diag3a will work and diag3b will fail. Yes, you're right! -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Mon, Apr 14 2014, Alan Stern wrote: How many diagnostic patches have you tried so far? I've lost track. Hi Alan, diag1: the one with the alan-timer diag2: reverts commit 0aa2832dd0d9d860 and instead, prints out information showing what the commit would do diag3: partially reverts e583d9db9960 and prints some information to the kernel log If you like, you can also apply the diagnostic patch that adds stuff to ohci-hcd. Yes, I've applied diag1 and diag3. The question is: With this patch present and no devices attached to the rear ports, do the front ports work with system suspend? Yes. Please find attached the log. -- Peter 2014-04-16T23:34:31.259973+02:00 micropit kernel: [ 370.035797] PM: Syncing filesystems ... done. 2014-04-16T23:34:31.260016+02:00 micropit kernel: [ 370.549062] PM: Preparing system for mem sleep 2014-04-16T23:34:52.719671+02:00 micropit kernel: [ 370.552283] Freezing user space processes ... (elapsed 0.001 seconds) done. 2014-04-16T23:34:52.719694+02:00 micropit kernel: [ 370.554235] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 2014-04-16T23:34:52.719695+02:00 micropit kernel: [ 370.555800] PM: Entering mem sleep 2014-04-16T23:34:52.719696+02:00 micropit kernel: [ 370.556327] ohci-pci :00:13.1: Dequeue: 8801240d0680 count 1 2014-04-16T23:34:52.719697+02:00 micropit kernel: [ 370.556363] usb 6-3: w-e-d 0 2014-04-16T23:34:52.719698+02:00 micropit kernel: [ 370.556370] usb 6-3: usb suspend, wakeup 0 2014-04-16T23:34:52.719698+02:00 micropit kernel: [ 370.556665] usb 2-3: w-e-d 0 2014-04-16T23:34:52.719699+02:00 micropit kernel: [ 370.556704] sd 2:0:0:0: [sdb] Synchronizing SCSI cache 2014-04-16T23:34:52.719701+02:00 micropit kernel: [ 370.556759] ohci-pci :00:13.1: IRQ: count 1 intr-en 805e intr-stat 24 frame f1a3 2014-04-16T23:34:52.719701+02:00 micropit kernel: [ 370.556765] sd 0:0:0:0: [sda] Synchronizing SCSI cache 2014-04-16T23:34:52.719702+02:00 micropit kernel: [ 370.556771] ohci-pci :00:13.1: Giveback: 8801240d0680 count 1 2014-04-16T23:34:52.719703+02:00 micropit kernel: [ 370.556867] sd 2:0:0:0: [sdb] Stopping disk 2014-04-16T23:34:52.719704+02:00 micropit kernel: [ 370.556958] usb usb7: usb auto-resume 2014-04-16T23:34:52.719705+02:00 micropit kernel: [ 370.556966] ohci-pci :00:14.5: resume root hub 2014-04-16T23:34:52.719706+02:00 micropit kernel: [ 370.557121] usb 2-3: usb suspend, wakeup 0 2014-04-16T23:34:52.719707+02:00 micropit kernel: [ 370.557225] usb usb5: usb auto-resume 2014-04-16T23:34:52.719708+02:00 micropit kernel: [ 370.557316] ohci-pci :00:13.0: resume root hub 2014-04-16T23:34:52.719708+02:00 micropit kernel: [ 370.557360] usb usb4: usb auto-resume 2014-04-16T23:34:52.719709+02:00 micropit kernel: [ 370.557372] ohci-pci :00:12.1: resume root hub 2014-04-16T23:34:52.719710+02:00 micropit kernel: [ 370.557447] usb usb3: usb auto-resume 2014-04-16T23:34:52.719711+02:00 micropit kernel: [ 370.557455] ohci-pci :00:12.0: resume root hub 2014-04-16T23:34:52.719712+02:00 micropit kernel: [ 370.557532] hub 2-0:1.0: hub_suspend 2014-04-16T23:34:52.719712+02:00 micropit kernel: [ 370.557542] usb usb2: bus suspend, wakeup 0 2014-04-16T23:34:52.719713+02:00 micropit kernel: [ 370.557546] ehci-pci :00:13.2: suspend root hub 2014-04-16T23:34:52.719714+02:00 micropit kernel: [ 370.557603] usb usb1: usb auto-resume 2014-04-16T23:34:52.719715+02:00 micropit kernel: [ 370.557611] ehci-pci :00:12.2: resume root hub 2014-04-16T23:34:52.719715+02:00 micropit kernel: [ 370.557798] usb 6-2: w-e-d 1 2014-04-16T23:34:52.719716+02:00 micropit kernel: [ 370.557805] usb 6-2: usb suspend, wakeup 1 2014-04-16T23:34:52.719717+02:00 micropit kernel: [ 370.557833] hub 6-0:1.0: hub_suspend 2014-04-16T23:34:52.719718+02:00 micropit kernel: [ 370.557839] usb usb6: bus suspend, wakeup 0 2014-04-16T23:34:52.719719+02:00 micropit kernel: [ 370.557850] ohci-pci :00:13.1: suspend root hub 2014-04-16T23:34:52.719719+02:00 micropit kernel: [ 370.601094] sd 0:0:0:0: [sda] Stopping disk 2014-04-16T23:34:52.719720+02:00 micropit kernel: [ 370.605358] hub 7-0:1.0: hub_resume 2014-04-16T23:34:52.719721+02:00 micropit kernel: [ 370.605514] hub 7-0:1.0: hub_suspend 2014-04-16T23:34:52.719722+02:00 micropit kernel: [ 370.605632] usb usb7: bus suspend, wakeup 0 2014-04-16T23:34:52.719722+02:00 micropit kernel: [ 370.605745] ohci-pci :00:14.5: suspend root hub 2014-04-16T23:34:52.719723+02:00 micropit kernel: [ 370.606397] hub 3-0:1.0: hub_resume 2014-04-16T23:34:52.719724+02:00 micropit kernel: [ 370.606410] hub 4-0:1.0: hub_resume 2014-04-16T23:34:52.719725+02:00 micropit kernel: [ 370.606438] hub 4-0:1.0: hub_suspend 2014-04-16T23:34:52.719726+02:00 micropit kernel: [ 370.606450] usb usb4: bus suspend, wakeup 0 2014-04-16T23:34:52.719726+02:00 micropit kernel: [ 370.606455] ohci-pci :00:12.1: suspend root hub
Re: problem with resume after s2ram
On Thu, 10 Apr 2014, Alan Stern wrote:
On Thu, 10 Apr 2014, Peter Münster wrote:
On Tue, Apr 01 2014, Alan Stern wrote:
Should I do another git-bisect?
Yes, that would be a good idea.
Hi Alan,
Here is the result:
e583d9db9960cf40e0bc8afee4946baa9d71596e is the first bad commit
commit e583d9db9960cf40e0bc8afee4946baa9d71596e
Author: Alan Stern st...@rowland.harvard.edu
Date: Thu Jul 11 14:58:04 2013 -0400
USB: global suspend and remote wakeup don't mix
I should have guessed... :-(
This is surprising, because this commit partially reverses the effect
of the other one. I don't see how it would make anything worse.
At some point I'll send you two more diagnostic patches, one for
testing with this commit applied and one for testing with this commit
reverted.
... And here's the first patch for you to try out.
We've got two separate problems, so to begin with, I'd like to
concentrate on the e583d9db9960 commit and why it messes up the front
ports. Once that's settled, we'll go back to 0aa2832dd0d9 and figure
out why it fails even though disabling CONFIG_USB_SUSPEND works.
How many diagnostic patches have you tried so far? I've lost track.
Let's call this one diag3. It should be applied directly to the
e583d9db9960 kernel; it partially reverts e583d9db9960 and prints some
information to the kernel log. If you like, you can also apply the
diagnostic patch that adds stuff to ohci-hcd.
The question is: With this patch present and no devices attached to the
rear ports, do the front ports work with system suspend? If not, what
does the kernel log show?
Alan Stern
Index: peter/drivers/usb/core/hub.c
===
--- peter.orig/drivers/usb/core/hub.c
+++ peter/drivers/usb/core/hub.c
@@ -2966,6 +2966,8 @@ int usb_port_suspend(struct usb_device *
return -ENOMEM;
}
+ dev_info(udev-dev, w-e-d %d\n, wakeup_enabled_descendants(udev));
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
@@ -2981,7 +2983,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (PMSG_IS_AUTO(msg))
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 01 2014, Alan Stern wrote: Should I do another git-bisect? Yes, that would be a good idea. Hi Alan, Here is the result: e583d9db9960cf40e0bc8afee4946baa9d71596e is the first bad commit commit e583d9db9960cf40e0bc8afee4946baa9d71596e Author: Alan Stern st...@rowland.harvard.edu Date: Thu Jul 11 14:58:04 2013 -0400 USB: global suspend and remote wakeup don't mix -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Thu, 10 Apr 2014, Peter Münster wrote: On Tue, Apr 01 2014, Alan Stern wrote: Should I do another git-bisect? Yes, that would be a good idea. Hi Alan, Here is the result: e583d9db9960cf40e0bc8afee4946baa9d71596e is the first bad commit commit e583d9db9960cf40e0bc8afee4946baa9d71596e Author: Alan Stern st...@rowland.harvard.edu Date: Thu Jul 11 14:58:04 2013 -0400 USB: global suspend and remote wakeup don't mix I should have guessed... :-( This is surprising, because this commit partially reverses the effect of the other one. I don't see how it would make anything worse. At some point I'll send you two more diagnostic patches, one for testing with this commit applied and one for testing with this commit reverted. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Wed, Apr 02 2014, Alan Stern wrote: Below is 0aa2832dd0d9d860 back-ported to 3.9. Please try testing a 3.9 kernel with this patch installed (and also the first diagnostic patch, if it applies with no errors), with CONFIG_USB_SUSPEND _enabled_ and the mouse plugged into the rear port. If this combination works, then maybe you can do yet another git-bisect. Search between 3.9 and 0aa2832dd0d9d860, and at each step merge this patch into the kernel you are testing before you build it. No, it does not work. Please find attached the log. -- Peter [ 207.379865] PM: Syncing filesystems ... done. [ 207.446504] PM: Preparing system for mem sleep [ 207.453621] ohci_hcd :00:12.1: Dequeue: 880122086cc0 count 1 [ 207.454080] ohci_hcd :00:12.1: IRQ: count 1 intr-en 805e intr-stat 24 frame 25e6 [ 207.454119] ohci_hcd :00:12.1: Giveback: 880122086cc0 count 1 [ 207.467685] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 207.479603] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 207.490595] PM: Entering mem sleep [ 207.491304] usb 4-3: usb suspend, wakeup 0 [ 207.491460] ohci_hcd :00:13.1: Dequeue: 880122086300 count 1 [ 207.491474] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 207.491546] usb 2-3: usb suspend, wakeup 0 [ 207.491594] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 207.491799] usb usb7: usb auto-resume [ 207.491829] ohci_hcd :00:14.5: resume root hub [ 207.491879] usb usb5: usb auto-resume [ 207.491902] ohci_hcd :00:13.0: resume root hub [ 207.492043] ohci_hcd :00:13.1: IRQ: count 1 intr-en 805e intr-stat 24 frame 259e [ 207.492207] ohci_hcd :00:13.1: Giveback: 880122086300 count 1 [ 207.492439] hub 4-0:1.0: hub_suspend [ 207.492482] usb usb4: bus suspend, wakeup 0 [ 207.492507] ohci_hcd :00:12.1: suspend root hub [ 207.492603] usb usb3: usb auto-resume [ 207.492665] ohci_hcd :00:12.0: resume root hub [ 207.492754] hub 2-0:1.0: hub_suspend [ 207.492788] usb usb2: bus suspend, wakeup 0 [ 207.492810] ehci-pci :00:13.2: suspend root hub [ 207.492875] usb usb1: usb auto-resume [ 207.492967] ehci-pci :00:12.2: resume root hub [ 207.493059] usb 6-3: usb suspend, wakeup 1 [ 210.437072] r8169 :02:00.0 eth0: link up [ 212.542512] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 212.566103] ata3.00: configured for UDMA/133 [ 212.570950] sd 2:0:0:0: [sdb] Starting disk [ 213.739414] ohci_hcd :00:12.1: Dequeue: 8800cc7ed180 count 1 [ 213.794366] ohci_hcd :00:13.1: Dequeue: 8800cfafb840 count 1 [ 213.796714] ohci_hcd :00:13.1: IRQ: count 1 intr-en 805a intr-stat 24 frame 25f0 [ 214.270943] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 214.288910] ata1.00: configured for UDMA/133 [ 214.293936] sd 0:0:0:0: [sda] Starting disk [ 223.747318] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 223.811297] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 233.754254] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 233.818228] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 243.761180] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 243.825161] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 253.768112] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 253.832091] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 263.775042] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 263.839021] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 273.781972] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 273.845952] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 283.788901] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 283.852879] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 293.795830] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 293.859810] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 303.802759] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 303.866746] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 313.809685] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 313.873665] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 323.816613] ohci_hcd :00:12.1: Timer: count 1 intr-en 805e intr-stat 20 frame 2627 [ 323.880592] ohci_hcd :00:13.1: Timer: count 1 intr-en 805e intr-stat 20 frame 25f0 [ 333.823531] ohci_hcd :00:12.1: Timer:
Re: problem with resume after s2ram
On Thu, Apr 10 2014, Alan Stern wrote: I should have guessed... :-( Next time, we can try some guesses before bisecting, right? -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Fri, Apr 04 2014, Alan Stern wrote: No error messages about hung-up tasks 120 seconds later? Sorry. I had forgotten to wait 2 minutes... Here again the log with information about hung-up tasks. -- Peter [ 97.307415] PM: Syncing filesystems ... done. [ 97.412888] PM: Preparing system for mem sleep [ 97.419642] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 97.421484] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 97.422709] PM: Entering mem sleep [ 97.423072] usb 6-3: usb suspend, wakeup 0 [ 97.423075] usb usb7: usb auto-resume [ 97.423082] ohci-pci :00:14.5: resume root hub [ 97.423092] usb 5-2: usb suspend, wakeup 0 [ 97.423183] hub 6-0:1.0: hub_suspend [ 97.423216] usb usb4: usb auto-resume [ 97.423229] ohci-pci :00:13.0: resume root hub [ 97.423254] usb usb3: usb auto-resume [ 97.423263] usb usb6: bus suspend, wakeup 0 [ 97.423266] ehci-pci :00:13.2: suspend root hub [ 97.423300] ohci-pci :00:12.1: resume root hub [ 97.423365] usb usb2: usb auto-resume [ 97.423392] ohci-pci :00:12.0: resume root hub [ 97.423555] usb usb1: usb auto-resume [ 97.423590] ehci-pci :00:12.2: resume root hub [ 97.423634] hub 1-0:1.0: hub_resume [ 97.423712] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 97.423715] hub 1-0:1.0: hub_suspend [ 97.423726] usb usb1: bus suspend, wakeup 0 [ 97.423728] ehci-pci :00:12.2: suspend root hub [ 97.423921] sd 2:0:0:0: [sdb] Stopping disk [ 97.423955] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 100.252067] r8169 :02:00.0 eth0: link up [ 102.54] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 102.551786] ata3.00: configured for UDMA/133 [ 102.553080] sd 2:0:0:0: [sdb] Starting disk [ 104.119856] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 104.136871] ata1.00: configured for UDMA/133 [ 104.141082] sd 0:0:0:0: [sda] Starting disk [ 241.758504] INFO: task s2ram:2466 blocked for more than 120 seconds. [ 241.762604] Not tainted 3.12.15-peter #11 [ 241.766582] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 241.770653] s2ram D 88012fc92f80 0 2466 2382 0x [ 241.774820] 880121b6dc60 0086 880121b6dfd8 00012f80 [ 241.779018] 880121b6dfd8 00012f80 880129136100 8801215cf0f8 [ 241.783217] 7fff 8801215cf0f0 880129136100 [ 241.787481] Call Trace: [ 241.791722] [815637d4] schedule+0x24/0x70 [ 241.796046] [81560f39] schedule_timeout+0x209/0x2a0 [ 241.800407] [8140235f] ? input_pass_values.part.4+0x4f/0x160 [ 241.804839] [8109c6de] ? ktime_get+0x3e/0xc0 [ 241.809302] [81562611] wait_for_completion+0x91/0x100 [ 241.813824] [81075900] ? wake_up_state+0x10/0x10 [ 241.818353] [813ab05f] dpm_wait+0x2f/0x40 [ 241.822916] [813ab0e0] device_resume+0x70/0x1e0 [ 241.827472] [813ac761] dpm_resume+0x111/0x240 [ 241.832060] [813acaac] dpm_resume_end+0xc/0x20 [ 241.836627] [81088bbd] suspend_devices_and_enter+0x21d/0x440 [ 241.841219] [81088f50] pm_suspend+0x170/0x250 [ 241.845802] [81087f87] state_store+0x97/0xa0 [ 241.850366] [812b44cf] kobj_attr_store+0xf/0x20 [ 241.854900] [811d45b1] sysfs_write_file+0xc1/0x140 [ 241.859422] [811665d8] vfs_write+0xb8/0x1e0 [ 241.863912] [81167004] SyS_write+0x44/0xa0 [ 241.868356] [8156c862] system_call_fastpath+0x16/0x1b [ 241.872849] INFO: task kworker/u12:95:2557 blocked for more than 120 seconds. [ 241.877386] Not tainted 3.12.15-peter #11 [ 241.881942] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 241.886611] kworker/u12:95 D 88012fc92f80 0 2557 2 0x [ 241.891355] Workqueue: events_unbound async_run_entry_fn [ 241.896108] 8800cd06bb50 0046 8800cd06bfd8 00012f80 [ 241.900978] 8800cd06bfd8 00012f80 880129580700 880121133540 [ 241.905857] 8800cd06bbc0 8800cd06bc34 1388 [ 241.910801] Call Trace: [ 241.915686] [815637d4] schedule+0x24/0x70 [ 241.920660] [a00e3675] usb_kill_urb+0x75/0xb0 [usbcore] [ 241.925654] [81067ca0] ? wake_up_atomic_t+0x30/0x30 [ 241.930681] [a00e3d78] usb_start_wait_urb+0xc8/0x150 [usbcore] [ 241.935743] [a00e3ebc] usb_control_msg+0xbc/0x100 [usbcore] [ 241.940833] [a00e4163] usb_get_status+0x73/0xc0 [usbcore] [ 241.945932] [a00dcb4c] usb_port_resume+0x2ac/0x5c0 [usbcore] [ 241.951052] [a00efd80] generic_resume+0x10/0x30 [usbcore] [ 241.956206] [a00e726f] usb_resume_both+0xff/0x140 [usbcore] [ 241.961337] [a00d7240] ? usb_dev_thaw+0x10/0x10 [usbcore] [ 241.966468] [a00e7daa] usb_resume+0x1a/0xd0
Re: problem with resume after s2ram
On Mon, 7 Apr 2014, Peter Münster wrote: On Fri, Apr 04 2014, Alan Stern wrote: No error messages about hung-up tasks 120 seconds later? Sorry. I had forgotten to wait 2 minutes... Here again the log with information about hung-up tasks. This looks a lot like what you got before. Apparently the problem is the same, even though the causes are different. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 01 2014, Alan Stern wrote: Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... Do you have a netconsole log? Hi Alan, Yes, here: [ 4694.420213] PM: Syncing filesystems ... done. [ 4694.591736] PM: Preparing system for mem sleep [ 4694.756151] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 4694.758468] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 4694.759870] PM: Entering mem sleep [ 4694.760313] usb 6-3: usb suspend, wakeup 0 [ 4694.760464] usb 2-3: usb suspend, wakeup 0 [ 4694.760520] usb usb7: usb auto-resume [ 4694.760578] ohci-pci :00:14.5: resume root hub [ 4694.760753] usb usb5: usb auto-resume [ 4694.760813] ohci-pci :00:13.0: resume root hub [ 4694.760908] usb usb4: usb auto-resume [ 4694.760961] ohci-pci :00:12.1: resume root hub [ 4694.761058] usb usb3: usb auto-resume [ 4694.761086] ohci-pci :00:12.0: resume root hub [ 4694.761300] hub 2-0:1.0: hub_suspend [ 4694.761340] usb usb1: usb auto-resume [ 4694.761396] ehci-pci :00:12.2: resume root hub [ 4694.761422] usb usb2: bus suspend, wakeup 0 [ 4694.761481] ehci-pci :00:13.2: suspend root hub [ 4694.761554] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 4694.761720] sd 2:0:0:0: [sdb] Stopping disk [ 4694.761862] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 4694.762063] sd 0:0:0:0: [sda] Stopping disk [ 4694.762223] usb 6-2: usb suspend, wakeup 1 [ 4697.508604] r8169 :02:00.0 eth0: link up [ 4699.733189] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4699.763610] ata3.00: configured for UDMA/133 [ 4699.768070] sd 2:0:0:0: [sdb] Starting disk [ 4701.366082] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4701.383352] ata1.00: configured for UDMA/133 [ 4701.387815] sd 0:0:0:0: [sda] Starting disk Should I do another git-bisect? Yes, that would be a good idea. Ok, but this will take some time. I can only do 1 or 2 reboots per day. -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Fri, 4 Apr 2014, Peter Münster wrote: On Tue, Apr 01 2014, Alan Stern wrote: Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... Do you have a netconsole log? Hi Alan, Yes, here: [ 4694.420213] PM: Syncing filesystems ... done. [ 4694.591736] PM: Preparing system for mem sleep [ 4694.756151] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 4694.758468] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 4694.759870] PM: Entering mem sleep [ 4694.760313] usb 6-3: usb suspend, wakeup 0 [ 4694.760464] usb 2-3: usb suspend, wakeup 0 [ 4694.760520] usb usb7: usb auto-resume [ 4694.760578] ohci-pci :00:14.5: resume root hub [ 4694.760753] usb usb5: usb auto-resume [ 4694.760813] ohci-pci :00:13.0: resume root hub [ 4694.760908] usb usb4: usb auto-resume [ 4694.760961] ohci-pci :00:12.1: resume root hub [ 4694.761058] usb usb3: usb auto-resume [ 4694.761086] ohci-pci :00:12.0: resume root hub [ 4694.761300] hub 2-0:1.0: hub_suspend [ 4694.761340] usb usb1: usb auto-resume [ 4694.761396] ehci-pci :00:12.2: resume root hub [ 4694.761422] usb usb2: bus suspend, wakeup 0 [ 4694.761481] ehci-pci :00:13.2: suspend root hub [ 4694.761554] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 4694.761720] sd 2:0:0:0: [sdb] Stopping disk [ 4694.761862] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 4694.762063] sd 0:0:0:0: [sda] Stopping disk [ 4694.762223] usb 6-2: usb suspend, wakeup 1 [ 4697.508604] r8169 :02:00.0 eth0: link up [ 4699.733189] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4699.763610] ata3.00: configured for UDMA/133 [ 4699.768070] sd 2:0:0:0: [sdb] Starting disk [ 4701.366082] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4701.383352] ata1.00: configured for UDMA/133 [ 4701.387815] sd 0:0:0:0: [sda] Starting disk No error messages about hung-up tasks 120 seconds later? Should I do another git-bisect? Yes, that would be a good idea. Ok, but this will take some time. I can only do 1 or 2 reboots per day. That's fine. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 1 Apr 2014, Peter Münster wrote:
On Tue, Apr 01 2014, Alan Stern wrote:
Also, I'd like to track down the problem when both devices are plugged
into front ports. Can you try that as well, again without the new
diagnostic patch? If the problem in this case is caused by a separate
bug then we may not learn anything, but it's worth a try.
Another thing I'd like to figure out is why 3.9 works okay when
CONFIG_USB_SUSPEND is disabled.
Below is 0aa2832dd0d9d860 back-ported to 3.9. Please try testing a 3.9
kernel with this patch installed (and also the first diagnostic patch,
if it applies with no errors), with CONFIG_USB_SUSPEND _enabled_ and
the mouse plugged into the rear port.
If this combination works, then maybe you can do yet another
git-bisect. Search between 3.9 and 0aa2832dd0d9d860, and at each step
merge this patch into the kernel you are testing before you build it.
Alan Stern
Index: 3.9/drivers/usb/core/hub.c
===
--- 3.9.orig/drivers/usb/core/hub.c
+++ 3.9/drivers/usb/core/hub.c
@@ -2880,9 +2880,11 @@ static int usb_disable_function_remotewa
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*
- * If CONFIG_USB_SUSPEND isn't enabled, devices only really suspend when
- * the root hub for their bus goes into global suspend ... so we don't
- * (falsely) update the device power state to say it suspended.
+ * If CONFIG_USB_SUSPEND isn't enabled, non-SuperSpeed devices really get
+ * suspended only when their bus goes into global suspend (i.e., the root
+ * hub is suspended). Nevertheless, we change @udev-state to
+ * USB_STATE_SUSPENDED as this is the device's logical state. The actual
+ * upstream port setting is stored in @udev-port_is_suspended.
*
* Returns 0 on success, else negative errno.
*/
@@ -2893,6 +2895,7 @@ int usb_port_suspend(struct usb_device *
enum pm_qos_flags_status pm_qos_stat;
int port1 = udev-portnum;
int status;
+ boolreally_suspend = true;
/* enable remote wakeup when appropriate; this lets the device
* wake up the upstream hub (including maybe the root hub).
@@ -2949,9 +2952,19 @@ int usb_port_suspend(struct usb_device *
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
- else
+ else if (PMSG_IS_AUTO(msg))
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
+ /*
+* For system suspend, we do not need to enable the suspend feature
+* on individual USB-2 ports. The devices will automatically go
+* into suspend a few ms after the root hub stops sending packets.
+* The USB 2.0 spec calls this global suspend.
+*/
+ else {
+ really_suspend = false;
+ status = 0;
+ }
if (status) {
dev_dbg(hub-intfdev, can't suspend port %d, status %d\n,
port1, status);
@@ -2987,8 +3000,10 @@ int usb_port_suspend(struct usb_device *
(PMSG_IS_AUTO(msg) ? auto- : ),
udev-do_remote_wakeup);
usb_set_device_state(udev, USB_STATE_SUSPENDED);
- udev-port_is_suspended = 1;
- msleep(10);
+ if (really_suspend) {
+ udev-port_is_suspended = 1;
+ msleep(10);
+ }
}
/*
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 01 2014, Alan Stern wrote: These all seem to be basically the same, apart from the Nouveau issue. This suggests that the previous test (i.e., without the new diagnostic patch) would have worked if _nothing_ was plugged into a front port and the keyboard was plugged into the rear port. Can you try that? Hi Alan, Yes. No hang in this case. Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... So it seems. This evidently is a problem in the hardware, and the final fix will have to work around it. Probably I'll end up adding code to ohci-hcd that will cancel out the effect of 0aa2832dd0d9d860 on all systems having that type of OHCI controller. Please provide the output from lspci -v -s 12.1 and lspci -v -n -s 12.1. # lspci -v -s 12.1 00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8389 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f8ffd000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci Kernel modules: ohci_pci # lspci -v -n -s 12.1 00:12.1 0c03: 1002:4398 (prog-if 10 [OHCI]) Subsystem: 1043:8389 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f8ffd000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci Kernel modules: ohci_pci Thanks for your efforts, -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Apr 01 2014, Alan Stern wrote: Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? If the problem in this case is caused by a separate bug then we may not learn anything, but it's worth a try. Should I do another git-bisect? -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 1 Apr 2014, Peter Münster wrote: On Tue, Apr 01 2014, Alan Stern wrote: These all seem to be basically the same, apart from the Nouveau issue. This suggests that the previous test (i.e., without the new diagnostic patch) would have worked if _nothing_ was plugged into a front port and the keyboard was plugged into the rear port. Can you try that? Hi Alan, Yes. No hang in this case. Good, at least something is making sense now. Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... Do you have a netconsole log? Should I do another git-bisect? Yes, that would be a good idea. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Mon, 31 Mar 2014, Peter Münster wrote: On Mon, Mar 31 2014, Alan Stern wrote: That's totally crazy. With wakeup enabled, the commit should have had no effect at all. Hi Alan, With 0aa2832dd0d9d860 kernel, the freeze happens only when something is connected to the rear port. But with later kernels (= 3.11), the freeze happens also without anything connected to the rear port. So maybe we're talking about more than one bug. I thought you had posted a log showing 3.12 working with no reversions and everything plugged into the front, but my memory must be wrong. (See also here: https://bugzilla.novell.com/show_bug.cgi?id=868315#c12 ) Here's another diagnostic patch to try (use it along with the first one). Do the same test, i.e., only the keyboard in a rear port. This patch effectively reverts commit 0aa2832dd0d9d860 and instead, prints out information showing what the commit would do. Please find attached 3 files: - messages-1.log: wake-up ok, but problem with nouveau or cpu. I guess, it was just bad luck and this has nothing to do with usb. I've had a similar lock-up already with 3.7 kernel. - messages-2.log: this time without X-server - messages-3.log: with X-server (and no lock-up this time) These all seem to be basically the same, apart from the Nouveau issue. This suggests that the previous test (i.e., without the new diagnostic patch) would have worked if _nothing_ was plugged into a front port and the keyboard was plugged into the rear port. Can you try that? Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? If the problem in this case is caused by a separate bug then we may not learn anything, but it's worth a try. (By the way, the first diagnostic patch did provide interesting information. Maybe you noticed: The frame values were _not_ changing!) Yes. I guess that means, that the usb-hub did not wake up? So it seems. This evidently is a problem in the hardware, and the final fix will have to work around it. Probably I'll end up adding code to ohci-hcd that will cancel out the effect of 0aa2832dd0d9d860 on all systems having that type of OHCI controller. Please provide the output from lspci -v -s 12.1 and lspci -v -n -s 12.1. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Fri, Mar 28 2014, Alan Stern wrote: This just raises more questions. It looks like it worked almost okay, but not quite. Certainly it didn't hang, so it isn't an exact reproduction of the problem. Can you run the same test again, and then at the end, do: echo 1 /sys/bus/usb/devices/4-2/bConfigurationValue (Actually this 1 should be whatever was in the file before you started the test -- it probably was 1 but it might be something else.) After that, the mouse should be working properly. Check it and see, and post the kernel log. (Don't bother to check the frame number values, since we already know they are changing.) Hi Alan, Yes, the mouse works again. Please find attached the log. Before the test, the value was 1. Just after the test, the file bConfigurationValue was empty. And after echo 1 the mouse works Back when you ran the system suspend test under the 3.9 kernel with CONFIG_USB_SUSPEND turned off, you said the system was okay after the resume. Does that mean the mouse and keyboard were working normally? Yes. One more thing... The bad commit should have no effect on devices enabled for wakeup -- and keyboards generally _are_ enabled for wakeup. Can you check this? Under 3.12.x with no patches or reversions, I've just added your diagnostic patch. plug the mouse into a front port and the keyboard into its usual rear port. Before going into suspend, make sure that the keyboard's power/wakeup file (/sys/bus/usb/devices/4-3/power/wakeup) contains enabled. Yes, it was already enabled. Then test if the suspend and resume work okay -- capture the log with netconsole and let's see what it says. The log is in attached file keyboard-rear.log. The resume hangs the system as usual. Finally, I'd like to get more information about what causes the system to hang when things go wrong. Below is a diagnostic patch for the 3.12 kernel -- you can keep the previous patch or remove it, it doesn't matter. This patch is intended to print information to the console every 10 seconds while the system is hung, so if it works then we should get some useful clues. Plug the mouse into the rear port and see what happens after a suspend. The log is in attached file mouse-rear.log. -- Peter 2014-03-31T00:11:34.483878+02:00 micropit kernel: [ 161.952812] usb 4-2: unregistering interface 4-2:1.0 2014-03-31T00:11:34.483912+02:00 micropit kernel: [ 161.952919] ohci-pci :00:12.1: shutdown urb 880120ba9e40 ep1in-intr 2014-03-31T00:11:34.523880+02:00 micropit kernel: [ 161.989995] usb 4-2: usb_disable_device nuking non-ep0 URBs 2014-03-31T00:11:37.271865+02:00 micropit kernel: [ 164.735103] usb 4-2: usb auto-suspend, wakeup 0 2014-03-31T00:11:37.271899+02:00 micropit kernel: [ 164.735124] hub 4-0:1.0: hub_suspend 2014-03-31T00:11:37.271903+02:00 micropit kernel: [ 164.735151] usb usb4: bus auto-suspend, wakeup 1 2014-03-31T00:11:37.271906+02:00 micropit kernel: [ 164.735161] ohci-pci :00:12.1: suspend root hub 2014-03-31T00:11:37.271909+02:00 micropit kernel: [ 164.735513] ohci-pci :00:12.1: hcd_pci_runtime_suspend: 0 2014-03-31T00:11:46.531887+02:00 micropit kernel: [ 173.990242] ohci-pci :00:12.1: powerup ports 2014-03-31T00:11:46.555904+02:00 micropit kernel: [ 174.010817] ohci-pci :00:12.1: hcd_pci_runtime_resume: 0 2014-03-31T00:11:46.555936+02:00 micropit kernel: [ 174.010839] usb usb4: usb auto-resume 2014-03-31T00:11:46.555939+02:00 micropit kernel: [ 174.010851] ohci-pci :00:12.1: resume root hub 2014-03-31T00:11:46.555942+02:00 micropit kernel: [ 174.010866] usb usb4: usb wakeup-resume 2014-03-31T00:11:46.627927+02:00 micropit kernel: [ 174.085767] hub 4-0:1.0: hub_resume 2014-03-31T00:11:46.627963+02:00 micropit kernel: [ 174.085922] hub 4-0:1.0: port 2: status 0303 change 2014-03-31T00:11:46.627967+02:00 micropit kernel: [ 174.086065] hub 4-0:1.0: state 7 ports 3 chg evt 2014-03-31T00:11:46.627970+02:00 micropit kernel: [ 174.086099] usb 4-2: finish resume 2014-03-31T00:11:46.627973+02:00 micropit kernel: [ 174.086728] ohci-pci :00:12.1: urb 880120ba9b40 path 2 ep0in 5ec2 cc 5 -- status -62 2014-03-31T00:11:46.627984+02:00 micropit kernel: [ 174.086817] usb 4-2: retry with reset-resume 2014-03-31T00:11:46.659853+02:00 micropit kernel: [ 174.116643] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 2014-03-31T00:11:46.663827+02:00 micropit kernel: [ 174.120241] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-31T00:11:46.739879+02:00 micropit kernel: [ 174.194644] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-31T00:11:46.863879+02:00 micropit kernel: [ 174.318514] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS 2014-03-31T00:11:46.919884+02:00 micropit kernel: [ 174.374499] usb 4-2: reset low-speed USB device number 2 using ohci-pci 2014-03-31T00:11:46.943879+02:00 micropit kernel: [
Re: problem with resume after s2ram
On Mon, 31 Mar 2014, Peter Münster wrote:
One more thing... The bad commit should have no effect on devices
enabled for wakeup -- and keyboards generally _are_ enabled for wakeup.
Can you check this? Under 3.12.x with no patches or reversions,
I've just added your diagnostic patch.
That's okay.
plug the mouse into a front port and the keyboard into its usual rear
port. Before going into suspend, make sure that the keyboard's
power/wakeup file (/sys/bus/usb/devices/4-3/power/wakeup) contains
enabled.
Yes, it was already enabled.
Then test if the suspend and resume work okay -- capture the log with
netconsole and let's see what it says.
The log is in attached file keyboard-rear.log.
The resume hangs the system as usual.
That's totally crazy. With wakeup enabled, the commit should have had
no effect at all.
Here's another diagnostic patch to try (use it along with the first
one). Do the same test, i.e., only the keyboard in a rear port. This
patch effectively reverts commit 0aa2832dd0d9d860 and instead, prints
out information showing what the commit would do.
(By the way, the first diagnostic patch did provide interesting
information. Maybe you noticed: The frame values were _not_ changing!)
Alan Stern
Index: usb-3.12/drivers/usb/core/hub.c
===
--- usb-3.12.orig/drivers/usb/core/hub.c
+++ usb-3.12/drivers/usb/core/hub.c
@@ -3021,10 +3021,13 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (1) {
+ dev_info(udev-dev, port suspend AUTO %d wakeup %d\n,
+ PMSG_IS_AUTO(msg),
+ wakeup_enabled_descendants(udev));
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
- else {
+ } else {
really_suspend = false;
status = 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Thu, 27 Mar 2014, Peter Münster wrote:
Hi Alan,
These are my commands:
echo 8 /proc/sys/kernel/printk
echo on /sys/bus/usb/devices/4-2/power/control
sleep 1
echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue
sleep 1
echo auto /sys/bus/pci/devices/:00:12.1/power/control
sleep 1
echo auto /sys/bus/usb/devices/4-2/power/control
sleep 10
echo on /sys/bus/usb/devices/4-2/power/control
Please find attached the kernel messages and the content of the
registers file once per second.
This just raises more questions. It looks like it worked almost okay,
but not quite. Certainly it didn't hang, so it isn't an exact
reproduction of the problem. Can you run the same test again, and then
at the end, do:
echo 1 /sys/bus/usb/devices/4-2/bConfigurationValue
(Actually this 1 should be whatever was in the file before you started
the test -- it probably was 1 but it might be something else.)
After that, the mouse should be working properly. Check it and see,
and post the kernel log. (Don't bother to check the frame number
values, since we already know they are changing.)
Back when you ran the system suspend test under the 3.9 kernel with
CONFIG_USB_SUSPEND turned off, you said the system was okay after the
resume. Does that mean the mouse and keyboard were working normally?
One more thing... The bad commit should have no effect on devices
enabled for wakeup -- and keyboards generally _are_ enabled for wakeup.
Can you check this? Under 3.12.x with no patches or reversions, plug
the mouse into a front port and the keyboard into its usual rear port.
Before going into suspend, make sure that the keyboard's power/wakeup
file (/sys/bus/usb/devices/4-3/power/wakeup) contains enabled.
(Write it to the file if the file says disabled.) Then test if the
suspend and resume work okay -- capture the log with netconsole and
let's see what it says.
Finally, I'd like to get more information about what causes the system
to hang when things go wrong. Below is a diagnostic patch for the 3.12
kernel -- you can keep the previous patch or remove it, it doesn't
matter. This patch is intended to print information to the console
every 10 seconds while the system is hung, so if it works then we
should get some useful clues. Plug the mouse into the rear port and
see what happens after a suspend.
Alan Stern
Index: usb-3.14/drivers/usb/host/ohci-hcd.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.14/drivers/usb/host/ohci-hcd.c
@@ -79,6 +79,19 @@ static const charhcd_name [] = ohci_hc
static void ohci_dump (struct ohci_hcd *ohci, int verbose);
static void ohci_stop (struct usb_hcd *hcd);
+static void alantimer_func(unsigned long _ohci)
+{
+ struct ohci_hcd *ohci = (struct ohci_hcd *) _ohci;
+
+ ohci_info(ohci, Timer: count %d intr-en %x intr-stat %x frame %x\n,
+ ohci-alancount,
+ ohci_readl(ohci, ohci-regs-intrenable),
+ ohci_readl(ohci, ohci-regs-intrstatus),
+ ohci_frame_no(ohci));
+ if (ohci-alancount 0)
+ mod_timer(ohci-alantimer, jiffies + HZ*10);
+}
+
#include ohci-hub.c
#include ohci-dbg.c
#include ohci-mem.c
@@ -289,6 +302,10 @@ static int ohci_urb_dequeue(struct usb_h
* handed to us, flag it for unlink and giveback, and force
* some upcoming INTR_SF to call finish_unlinks()
*/
+ if (ohci-alancount == 0)
+ mod_timer(ohci-alantimer, jiffies + HZ*10);
+ ohci_info(ohci, Dequeue: %p count %d\n, urb,
+ ++ohci-alancount);
urb_priv = urb-hcpriv;
if (urb_priv) {
if (urb_priv-ed-state == ED_OPER)
@@ -299,6 +316,8 @@ static int ohci_urb_dequeue(struct usb_h
* with HC dead, we won't respect hc queue pointers
* any more ... just clean up every urb's memory.
*/
+ ohci_info(ohci, Dequeue: %p count %d\n, urb,
+ ++ohci-alancount);
if (urb-hcpriv)
finish_urb(ohci, urb, status);
}
@@ -745,6 +764,7 @@ retry:
}
ohci_dump (ohci, 1);
+ setup_timer(ohci-alantimer, alantimer_func, (unsigned long) ohci);
return 0;
}
@@ -801,6 +821,12 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
+ if (ohci-alancount 0)
+ ohci_info(ohci, IRQ: count %d intr-en %x intr-stat %x frame
%x\n,
+ ohci-alancount,
+ ohci_readl(ohci, regs-intrenable), ints,
+ ohci_frame_no(ohci));
+
/* We only care about interrupts that are enabled */
ints = ohci_readl(ohci, regs-intrenable);
Index:
Re: problem with resume after s2ram
On Wed, 26 Mar 2014, Peter Münster wrote: On Wed, Mar 26 2014, Alan Stern wrote: Please try running the test again. When it finishes, go to the /sys/kernel/debug/usb/ohci/:00:12.1/ directory and post a copy of the registers file. Check the contents of that file several times; in the line that says hcca frame, the value should change over time. Does it? Yes, it does. Please find attached the kernel messages and the output of this command: while sleep 1; do date; cat registers; echo; done /tmp/registers.log Oops -- I just realized that the instructions I sent you before were incomplete. Please try running the same test again, but this time issue the following commands to suspend the device: echo on /sys/bus/usb/devices/4-2/power/control echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue echo auto /sys/bus/pci/devices/:00:12.1/power/control echo auto /sys/bus/usb/devices/4-2/power/control Then a few seconds later, the following command to resume the device: echo on /sys/bus/usb/devices/4-2/power/control Without the write to the PCI device, the USB controller did not go into suspend and so it wasn't a valid test. As for the changing hcca frame value, that was just a wild guess on my part. Still, if you find it's _not_ changing after this new test, that would explain the problem you experienced. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Thu, Mar 27 2014, Alan Stern wrote: Oops -- I just realized that the instructions I sent you before were incomplete. Please try running the same test again, but this time issue the following commands to suspend the device: echo on /sys/bus/usb/devices/4-2/power/control echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue echo auto /sys/bus/pci/devices/:00:12.1/power/control echo auto /sys/bus/usb/devices/4-2/power/control Then a few seconds later, the following command to resume the device: echo on /sys/bus/usb/devices/4-2/power/control Without the write to the PCI device, the USB controller did not go into suspend and so it wasn't a valid test. Hi Alan, These are my commands: echo 8 /proc/sys/kernel/printk echo on /sys/bus/usb/devices/4-2/power/control sleep 1 echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue sleep 1 echo auto /sys/bus/pci/devices/:00:12.1/power/control sleep 1 echo auto /sys/bus/usb/devices/4-2/power/control sleep 10 echo on /sys/bus/usb/devices/4-2/power/control Please find attached the kernel messages and the content of the registers file once per second. As for the changing hcca frame value, that was just a wild guess on my part. Still, if you find it's _not_ changing after this new test, that would explain the problem you experienced. It's still changing. -- Peter 2014-03-27T21:49:34.060126+01:00 micropit kernel: [ 192.519501] usb 4-2: unregistering interface 4-2:1.0 2014-03-27T21:49:34.060161+01:00 micropit kernel: [ 192.519608] ohci-pci :00:12.1: shutdown urb 8801210a1240 ep1in-intr 2014-03-27T21:49:34.100112+01:00 micropit kernel: [ 192.558362] usb 4-2: usb_disable_device nuking non-ep0 URBs 2014-03-27T21:49:36.564126+01:00 micropit kernel: [ 195.023277] usb 4-2: usb auto-suspend, wakeup 0 2014-03-27T21:49:36.564162+01:00 micropit kernel: [ 195.023298] hub 4-0:1.0: hub_suspend 2014-03-27T21:49:36.564165+01:00 micropit kernel: [ 195.023324] usb usb4: bus auto-suspend, wakeup 1 2014-03-27T21:49:36.564168+01:00 micropit kernel: [ 195.023334] ohci-pci :00:12.1: suspend root hub 2014-03-27T21:49:36.564171+01:00 micropit kernel: [ 195.023686] ohci-pci :00:12.1: hcd_pci_runtime_suspend: 0 2014-03-27T21:49:46.108132+01:00 micropit kernel: [ 204.575426] ohci-pci :00:12.1: powerup ports 2014-03-27T21:49:46.132137+01:00 micropit kernel: [ 204.596549] ohci-pci :00:12.1: hcd_pci_runtime_resume: 0 2014-03-27T21:49:46.132172+01:00 micropit kernel: [ 204.596569] usb usb4: usb auto-resume 2014-03-27T21:49:46.132175+01:00 micropit kernel: [ 204.596581] ohci-pci :00:12.1: resume root hub 2014-03-27T21:49:46.132178+01:00 micropit kernel: [ 204.596594] usb usb4: usb wakeup-resume 2014-03-27T21:49:46.204123+01:00 micropit kernel: [ 204.671043] hub 4-0:1.0: hub_resume 2014-03-27T21:49:46.204159+01:00 micropit kernel: [ 204.671198] hub 4-0:1.0: port 2: status 0303 change 2014-03-27T21:49:46.204163+01:00 micropit kernel: [ 204.671299] hub 4-0:1.0: state 7 ports 3 chg evt 2014-03-27T21:49:46.204166+01:00 micropit kernel: [ 204.671379] usb 4-2: finish resume 2014-03-27T21:49:46.204178+01:00 micropit kernel: [ 204.672598] ohci-pci :00:12.1: urb 8801214e8a40 path 2 ep0in 5ec2 cc 5 -- status -62 2014-03-27T21:49:46.208145+01:00 micropit kernel: [ 204.672681] usb 4-2: retry with reset-resume 2014-03-27T21:49:46.236076+01:00 micropit kernel: [ 204.702512] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 2014-03-27T21:49:46.240071+01:00 micropit kernel: [ 204.705874] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.252140+01:00 micropit kernel: [ 204.716594] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.440125+01:00 micropit kernel: [ 204.904711] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS 2014-03-27T21:49:46.496125+01:00 micropit kernel: [ 204.960790] usb 4-2: reset low-speed USB device number 2 using ohci-pci 2014-03-27T21:49:46.520096+01:00 micropit kernel: [ 204.986657] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 2014-03-27T21:49:46.524124+01:00 micropit kernel: [ 204.991077] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.724127+01:00 micropit kernel: [ 205.188863] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS 2014-03-27T21:49:46.748115+01:00 micropit kernel: [ 205.212901] hub 4-0:1.0: state 7 ports 3 chg evt 0004 Thu Mar 27 21:49:32 CET 2014 bus pci, device :00:12.1 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x28f RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead ce648000 hcca frame 0xd93f fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001c09 FRT FR=0x1c09 periodicstart 0x2a2f lsthresh 0x0628 hub
Re: problem with resume after s2ram
On Tue, 25 Mar 2014, Peter Münster wrote: On Tue, Mar 25 2014, Alan Stern wrote: Below is a patch you should apply to normal 3.14 (nothing reverted). Hi Alan, I've used 3.12.14, because the source-tree is already set up. I hope that this is ok. Yes. For this test, plug some device you aren't going to use (the mouse, for example, if you will be at a VT console instead of a graphics console) into the rear port normally used by the mouse. Plug the keyboard and anything else into front ports -- no other devices should be attached to a rear port. Then you can force the test device to go into runtime suspend by typing this: echo auto /sys/bus/usb/devices/4-2/power/control echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue (I believe 4-2 is the correct path for the rear port where you like to plug the mouse.) After 5 seconds or so, force the device to resume by typing: echo on /sys/bus/usb/devices/4-2/power/control Let's see what shows up in the kernel log. With luck the resume will hang but the rest of your system will keep on running. No more mouse after the test, but the rest of the system works. Please find attached the log (copied from /var/log/messages). Here my commands: echo 8 /proc/sys/kernel/printk echo auto /sys/bus/usb/devices/4-2/power/control sleep 2 echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue sleep 10 echo on /sys/bus/usb/devices/4-2/power/control This was a good test. It clearly shows there's something wrong with the USB controller hardware. Maybe it simply can't handle global suspend. Please try running the test again. When it finishes, go to the /sys/kernel/debug/usb/ohci/:00:12.1/ directory and post a copy of the registers file. Check the contents of that file several times; in the line that says hcca frame, the value should change over time. Does it? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 25 Mar 2014, Peter Münster wrote:
On Mon, Mar 24 2014, Alan Stern wrote:
All three files show the system hanging after the resume, even the file
with nothing in the rear ports. Also, the logs are incomplete; it
looks like a bunch of stuff is missing from the start of the suspend.
Did you use netconsole to collect the logs?
Hi,
Yes. And just before, I've made echo 8 /proc/sys/kernel/printk
Okay. I guess netconsole doesn't work very well during system suspend.
Oddly, this log is much more complete than the others. Did you collect
it the same way?
No. I've used /var/log/messages.
That explains why it is more complete.
This is very puzzling. Let's try one more combination. Can you
collect a log showing 3.14 with commit 0aa2832dd0d9d8 reverted and the
mouse keyboard both plugged into the rear ports?
Yes. Please find attached the log (kernel 3.12.14). I attach also the
hub.c that I use, because there were conflicts, that I've resolved
manually.
This looks normal.
Clearly we aren't making much progress, mainly because it's so hard to
get debugging data during system suspend. So let's try something else
-- maybe the same problem will arise during runtime suspend.
Below is a patch you should apply to normal 3.14 (nothing reverted).
It will cause the 0aa2832dd0d9d8 change to take effect during runtime
suspend as well as system suspend.
For this test, plug some device you aren't going to use (the mouse, for
example, if you will be at a VT console instead of a graphics console)
into the rear port normally used by the mouse. Plug the keyboard and
anything else into front ports -- no other devices should be attached
to a rear port.
Then you can force the test device to go into runtime suspend by typing
this:
echo auto /sys/bus/usb/devices/4-2/power/control
echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue
(I believe 4-2 is the correct path for the rear port where you like to
plug the mouse.)
After 5 seconds or so, force the device to resume by typing:
echo on /sys/bus/usb/devices/4-2/power/control
Let's see what shows up in the kernel log. With luck the resume will
hang but the rest of your system will keep on running.
Alan Stern
Index: usb-3.14/drivers/usb/core/hub.c
===
--- usb-3.14.orig/drivers/usb/core/hub.c
+++ usb-3.14/drivers/usb/core/hub.c
@@ -3015,7 +3015,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (0)
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, Mar 25 2014, Alan Stern wrote: Below is a patch you should apply to normal 3.14 (nothing reverted). Hi Alan, I've used 3.12.14, because the source-tree is already set up. I hope that this is ok. For this test, plug some device you aren't going to use (the mouse, for example, if you will be at a VT console instead of a graphics console) into the rear port normally used by the mouse. Plug the keyboard and anything else into front ports -- no other devices should be attached to a rear port. Then you can force the test device to go into runtime suspend by typing this: echo auto /sys/bus/usb/devices/4-2/power/control echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue (I believe 4-2 is the correct path for the rear port where you like to plug the mouse.) After 5 seconds or so, force the device to resume by typing: echo on /sys/bus/usb/devices/4-2/power/control Let's see what shows up in the kernel log. With luck the resume will hang but the rest of your system will keep on running. No more mouse after the test, but the rest of the system works. Please find attached the log (copied from /var/log/messages). Here my commands: echo 8 /proc/sys/kernel/printk echo auto /sys/bus/usb/devices/4-2/power/control sleep 2 echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue sleep 10 echo on /sys/bus/usb/devices/4-2/power/control -- Peter kernel: [ 103.387198] usb 4-2: usb auto-suspend, wakeup 1 kernel: [ 103.387911] hub 4-0:1.0: hub_suspend kernel: [ 103.387945] usb usb4: bus auto-suspend, wakeup 1 kernel: [ 103.387955] ohci-pci :00:12.1: suspend root hub kernel: [ 105.441905] usb usb4: usb auto-resume kernel: [ 105.441923] ohci-pci :00:12.1: resume root hub kernel: [ 105.515991] hub 4-0:1.0: hub_resume kernel: [ 105.516127] hub 4-0:1.0: port 2: status 0303 change kernel: [ 105.516253] hub 4-0:1.0: state 7 ports 3 chg evt kernel: [ 105.516311] usb 4-2: finish resume kernel: [ 105.516995] ohci-pci :00:12.1: urb 88012188f8c0 path 2 ep0in 5ec2 cc 5 -- status -62 kernel: [ 105.517033] usb 4-2: retry with reset-resume kernel: [ 105.546948] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 105.550068] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 105.717102] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 105.749125] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 105.805213] usb 4-2: reset low-speed USB device number 2 using ohci-pci kernel: [ 105.831072] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 105.965243] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 106.033264] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 106.121391] usb 4-2: unregistering interface 4-2:1.0 kernel: [ 106.121496] ohci-pci :00:12.1: shutdown urb 8800cfa85380 ep1in-intr kernel: [ 106.149844] usb 4-2: usb_disable_device nuking non-ep0 URBs kernel: [ 108.150409] usb 4-2: usb auto-suspend, wakeup 0 kernel: [ 108.150429] hub 4-0:1.0: hub_suspend kernel: [ 108.150456] usb usb4: bus auto-suspend, wakeup 1 kernel: [ 108.150465] ohci-pci :00:12.1: suspend root hub kernel: [ 116.159228] usb usb4: usb auto-resume kernel: [ 116.159246] ohci-pci :00:12.1: resume root hub kernel: [ 116.233915] hub 4-0:1.0: hub_resume kernel: [ 116.234070] hub 4-0:1.0: port 2: status 0303 change kernel: [ 116.234179] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.234255] usb 4-2: finish resume kernel: [ 116.234880] ohci-pci :00:12.1: urb 8800ce12b2c0 path 2 ep0in 5ec2 cc 5 -- status -62 kernel: [ 116.234977] usb 4-2: retry with reset-resume kernel: [ 116.264823] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 116.268901] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.386971] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.466997] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 116.523077] usb 4-2: reset low-speed USB device number 2 using ohci-pci kernel: [ 116.548990] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 116.635142] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.751153] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
Re: problem with resume after s2ram
On Thu, 20 Mar 2014, Peter Münster wrote: I'd like to see a comparable log showing what happens when you suspend with only the mouse plugged in to a rear port, and one with only the keyboard plugged in to the rear. No serial ports or other stuff. Please find attached 3 files: - with keyboard in rear port - with mouse in rear port - with nothing in rear port All three files show the system hanging after the resume, even the file with nothing in the rear ports. Also, the logs are incomplete; it looks like a bunch of stuff is missing from the start of the suspend. Did you use netconsole to collect the logs? But it wakes up after pressing the power-button. The system is ok after resume. Please find attached the log. The kernel is 3.9.11 with CONFIG_USB_DEBUG turned on and with CONFIG_USB_SUSPEND turned off. Please post a log for the same kernel version and settings but with CONFIG_USB_SUSPEND turned back on. This log is also attached. Oddly, this log is much more complete than the others. Did you collect it the same way? This is very puzzling. Let's try one more combination. Can you collect a log showing 3.14 with commit 0aa2832dd0d9d8 reverted and the mouse keyboard both plugged into the rear ports? Offhand, I'd say there's something wrong with the USB controller hardware on the motherboard. With incomplete information, though, it's hard to tell for certain. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Wed, 19 Mar 2014, Peter Münster wrote: On Tue, Mar 18 2014, Alan Stern wrote: Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for my system: You should include the name of the commit along with the hash ID; otherwise nobody will know what it is unless they go to the trouble of looking it up for themselves. You also should address your email to the author of the commit. Otherwise your message is very likely to get overlooked. Hi, Sorry, next time I'll do it better. (I thought that the link to the initial report would have been enough...) No, it isn't, because nobody will know what the initial report says unless they click on the link. You have to provide enough information in the email itself for readers to judge whether they should pay attention to it, without requiring them to do any extra work to find out. Otherwise they will simply ignore the message. What do you get if you boot with no_console_suspend on the kernel command line and do echo 8 /proc/sys/kernel/printk before starting the suspend? Please see attached photo. It's the 3.12.14 kernel. Okay. It shows what happened, but not the reason for the crash. In the photo, what were the two devices plugged into the rear ports? It looks like one of them was a keyboard or mouse, but the other seems to be a serial port. Can you use netconsole to capture the log messages, instead of taking a picture of the screen? See the instructions in Documentation/networking/netconsole.txt. (You'll need another computer to capture the messages.) Do you have CONFIG_DETECT_HUNG_TASK enabled? If not, please turn it on. Then after you get a hang, wait a couple of minutes to see if any extra messages show up. I'd like to see a comparable log showing what happens when you suspend with only the mouse plugged in to a rear port, and one with only the keyboard plugged in to the rear. No serial ports or other stuff. Also, can you turn on CONFIG_USB_DEBUG? Yes, done. What happens if you run a kernel that doesn't have that commit, such as 3.9 or earlier, and you turn off CONFIG_USB_SUSPEND? When pressing a key on the mouse or the keyboard, the system does not wake-up. That's right; without CONFIG_USB_SUSPEND there is no support for USB wakeup. But it wakes up after pressing the power-button. The system is ok after resume. Please find attached the log. The kernel is 3.9.11 with CONFIG_USB_DEBUG turned on and with CONFIG_USB_SUSPEND turned off. Please post a log for the same kernel version and settings but with CONFIG_USB_SUSPEND turned back on. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problem with resume after s2ram
Hi, Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for my system: When it wakes up after s2ram, it freezes. Screen is black, keyboard does not work, no ssh-connection. Just the network-ping works. Please see here for more details, especially information about the hardware: https://bugzilla.novell.com/show_bug.cgi?id=868315 TIA for any help, -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 18 Mar 2014, Peter Münster wrote: Hi, Commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 introduces a problem for my system: You should include the name of the commit along with the hash ID; otherwise nobody will know what it is unless they go to the trouble of looking it up for themselves. You also should address your email to the author of the commit. Otherwise your message is very likely to get overlooked. When it wakes up after s2ram, it freezes. Screen is black, keyboard does not work, no ssh-connection. Just the network-ping works. What do you get if you boot with no_console_suspend on the kernel command line and do echo 8 /proc/sys/kernel/printk before starting the suspend? Also, can you turn on CONFIG_USB_DEBUG? Please see here for more details, especially information about the hardware: https://bugzilla.novell.com/show_bug.cgi?id=868315 What happens if you run a kernel that doesn't have that commit, such as 3.9 or earlier, and you turn off CONFIG_USB_SUSPEND? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
